Developer CD Series 1994 …ember: Reference Library/Dev.CD Dec 94.toast/Technical Documentation/Mac Tech Notes (DocViewer)/HW • Hardware/HW01 ADB (Space Aliens)/HW01 ADB (Space Aliens)

Text File | 1994-10-19 | 156.0 KB | 270 lines | [ONLN/HLX2]

ADB–The Untold Story : Space Aliens Ate My Mouse
Hardware
Written by:    Tim Dierks, Jim Mensch    January 1994
Originally by:    Cameron Birse, Rich Kubota
This Technical Note explains a number of esoteric and unknown issues concerning the Apple Desktop Bus (ADB).  It incorporates material from the original version of this note, along with a large amount of new information, and is intended to detail information concerning all levels of the ADB, from the hardware to the application usage level.  This note is supplementary to the information in The Guide To Macintosh Family Hardware and in the Apple Desktop Bus Specification. The information in the specification is the most accurate source of data, and unless it is specifically refuted, it should be treated as the authoritative source.
Changes since October 1991:  This note has been rewritten; new information appears throughout the document.  In particular, the Cursor Device Manager is discussed in this note for the first time. The information regarding bugs fixed in System 6.0.4 was omitted.
Topics
•    A discussion of ADB hardware issues
•    Information on the ADB protocol, including a detailed description of the relocation and autopolling mechanisms.
•    The recommended method of ADB driver installation
•    Documentation for the Cursor Device Manager
•    Description of the data formats used by Apple mice and keyboards
•    How to get an ADB license
The ADB Hardware
The ADB is a simple serial bus with collision detection.  A common implementation platform for the protocol is a simple microcontroller; a 2 MHz Motorola 68HC11 has been used with success, although any number of microcontrollers would do a more than adequate job.  The 2 MHz clock seemed to be close to minimal for this application.  The bus has a relatively low bandwidth; given the packet structure, the theoretical maximum bandwidth is on the order of 100 - 200 bytes/second.  In practice, the bus is not suitable for data transfer applications; it serves well as a general purpose input device bus, but high data rates will not work well.
In general, the timing for the ADB is fairly tolerant of small variances; however, many recent Macintoshes are more demanding than their predecessors. For this reason, devices should be tested on a wide range of machines; the best test for compliance is testing.  Specifically, the Tlt (stop to start time) parameter has become much less tolerant in recent Macintoshes; fairly close adherence to its 200 µs timing is important.  In particular, devices which respond more rapidly than the 140 µs minimum delay will often fail to initialize properly.
It is important that your device be fairly tolerant of problems on the bus; if a command packet begins but never seems to complete, your device should time out rather than hang; the design of the bus and its connectors means that there can be occasional glitches in the connection with the host, and you should try to be as tolerant of these as possible.
Because the ADB bus is open collector, collisions can be detected when a device is attempting to drive the bus high and another device pulls it low.  This means that whenever the device is driving the bus high, it should be watching to make sure the bus is actually high; if the bus goes low, some other device is sending at the same time. When a device detects a collision, it should immediately stop transmitting; this means that if two devices are colliding, one of them will detect the collision, while one will not.  This is because a device can only detect the collision if it is driving the bus high and another device drives it low.  The device driving it low has no way to tell that there was a collision, as the bus follows it.  Since the detecting device immediately stops transmitting, the other device will not detect the collision.  Thus, if there are a number of devices transmitting on the bus, only one of them will complete its transmission without detecting the collision, unless the unlikely occurrence of more than one device transmitting exactly the same data with the same timing occurs, and neither detects the collision.
The ADB is not particularly tolerant of devices being connected and disconnected while the bus is live. There isn't any software architecture to detect the presence of new devices or the absence of old ones; furthermore, on some CPUs, the motherboard is not well protected from voltage transients on the ADB connector; plugging in a device while the Macintosh is on could cause damage to the ADB transceiver or other portions of the Macintosh's circuitry.
On some portable Macintoshes, the voltage characteristics are not exactly what is specified in the ADB spec.  Clearly, power is very valuable on all portable computers, so if your device is targeted towards portable use, you should be extremely careful to keep your power consumption as low as possible; while the ADB can supply the full voltage specified in the spec., drawing this much power will lead to much more rapid battery draining. On the PowerBook 140 and 170, there was a specific problem which caused the low-level input voltage to go above the specified maximum of 0.8 volts; it commonly came close to 1.5 volts. This has caused problems for some third-party devices; it has been corrected on all more recent machines. There is a recommended service procedure for repairing this problem available from Apple Service representatives, should this be a problem for a user.
Soft Power
On Macintoshes with software power control, the machine can be turned on by an ADB device.  This is accomplished by momentarily connecting pin 2 on the ADB connector (reserved) to pin 4 (ground).  Pin 2 should be kept grounded until pin 3 (+5 volts) comes up to power, letting you know that the machine has actually come on.  Some Macintoshes do not have soft power capabilities; on these machines, grounding pin 2 will have no effect.
The ADB Protocol
Registers
Each ADB device has four logical registers; the host can ask the device to talk or listen on each one of these registers; a talk command asks the device to output the stored value from that register; a listen commands asks the device to accept a new value for that register.  A register can contain between 2 and 8 bytes.  Some of the registers have predefined functions: register 0 is used as the primary data transfer register for most devices; it is this register which is polled by the input mechanism (as described below).  Register 1 has no specified use; it is available for any use the device might require.  Register 2 has no specified use for most devices; the ADB specification does define an "extended address device" protocol for register 2 on devices at address 1, but this is unused by most developers.  Register 3 is used to identify devices and to separate devices which occupy the same address, as discussed in "Address Resolution" below.
Default addresses and handler IDs
Each ADB device identifies its software interface with two constants; the default address and the handler ID.  This pair uniquely identifies a device's software interface; the default address usually specifies a device's general type (such as relative pointing device or keyboard) while the handler ID specified the particular data protocol this device uses for communication.  The default address categories are as follows:
Default Address
Device Type
1    Security & Dongles
2    Keyboards
3    Relative pointing devices (mice)
4    Absolute pointing devices (tablets)
5    Low speed data transfer devices
6    Reserved (PowerBook Duo charger)
7    Appliances (Miscellaneous catch-all)

Table 1–Default address categories
The default address is only a guide; there's no real reason a mouse can't be at address 7, but default addresses are assigned on a category basis to try to avoid the case where a user has more than one device at a particular address; by putting all the relative devices at address 3, collisions will be avoided at address 3 for all users who have only one relative pointing device.  While the bus is robust with respect to seperating devices which are at the same address, the ADBS driver loading mechanism, which is described blow, made it useful to try to avoid having several dissimilar devices at the same address.
Default addresses and handler IDs are assigned by Apple Software Licensing when an ADB license contract is completed.  Default address 0 is used by the ADB host; addresses 8 through 15 are used as locations to dynamically locate devices at.
Some devices support more than one data protocol.  An example is the extended keyboard, which can be asked to send separate key codes for the left & right shift keys.  This change is accomplished by changing its handler ID to 3; the new handler ID reflects the new data protocol.  If your device receives a request to change handler IDs (via a listen register 3 command), it should only obey the request if it knows how to speak the protocol specified by the new handler ID.  For example, the extended keyboard, when receiving a request to change handler IDs, should accept the change if it is going to ID 3 or some other ID it knows about, and should thereafter report that ID as its own in response to talk register 3 commands; if it receives a request to change to handler ID $52, it should ignore it, as it does not know what handler ID $52 implies, and continue to report its original handler ID in response to talk register 3 commands.
A special case is devices which emulate Apple device protocols.  For example, you may be constructing a 17-button mouse for use by specially trained squid; it has a special software protocol to allow it to convey the state of all 17 mouse buttons.  However, you may wish to emulate the Apple mouse protocol so your device can be used as a one button mouse on machines which don't have your driver software installed.  Due to the software design of the ADB manager, if your device is at default address 3, it will have the default mouse driver installed as its driver at startup regardless of its handler ID; when your software loads, you can install a new driver for your device and tell it to begin talking the 17 button protocol.  You have two options: you can have your device power up with the default Apple mouse handler ID ($01) or with your own handler ID as assigned by Apple Software Licensing.  If you power up with the $01 handler ID, your software will have to locate your device by trying to change the handler ID of each device which started out at address 3 to you custom ID, then reading the handler ID of that device back; if the change stuck, then you know you're talking to your device, and can install your custom driver.  In addition, the command to change handler IDs told the device to begin using your custom protocol.  Alternatively, you could have your device power up with your custom handler ID; this would make identifying your device somewhat easier, as your device could be identified by its special handler ID; you would have to use some special command to tell the device that you have installed the new driver and that it can begin speaking the custom protocol.  For example, you could use a talk register 1 to tell the device that you're ready for the 17 button data protocol.  Both approaches work well, but the first one is recommended; it ensures that the current protocol can always be determined by looking at the current handler ID; however, it relies on all devices at that default address handling commands asking them to change to a different handler ID properly, as a device which incorrectly changes its handler ID to your assigned ID would fool you into thinking it was your device.  This doesn't seem to be a large problem, but there could be some obscure devices with this bug.
Address Resolution
Address resolution is the process the ADB manager uses to separate devices which share the same default address, so they power up shadowing each other at a particular address.  It relies on devices using collision detection to determine when there is more than one device at a particular address.
An ADB device's register 3 is 2 bytes long and includes 4 bits in which the address is stored.  When the device receives a listen register 3 command, it should take its address from this 4 bit field.  When it receives a talk register 3 command, it would be redundant to put the device's address in that field; the device's address is already uniquely determined by the fact that the device is responding to the talk register 3 command, which was sent to a specific address.  Instead, a random 4-bit value should be returned in this field; this makes it easier to detect collisions between two devices responding to a talk register 3.
When a device receives a talk register 3 command, it should send back all of register 3, including the random field, and it should pay careful attention to collision detection. Should a device detect a collision when responding to a talk register 3 request, there is a special provision in the ADB protocol which says that the device should ignore the next listen register 3 which asks it to change address. The next time the device receives a listen register 3 command, it should check to see if the handler ID field is set to $FE.  This is a reserved handler ID used to distinguish this type of listen request; if the handler ID field is $FE, the device should only change address if it has safely transmitted a complete packet since its last collision.  Of course, the device should not adopt the handler ID of $FE.
Here is a summary of a typical sequence where the host is attempting to separate two devices.  There are two devices of the same type, which I will call Fred and Wilma, at address 3.
1) The host will send a talk register 3 command to address 3.
2) Both Fred and Wilma will receive the command and begin to respond.
3) Even though they are sending the same data, and they begin sending at the same time, they select different random numbers to insert into the "device address" field of register 3, bits 7-10.
4) Wilma detects a collision while trying to send bit 7 and immediately stops sending.
5) Fred does not detect a collision and completes his transmission of register 3.
6) The host, seeing that a device has responded to its talk register 3, sends a listen register 3 to address 3, asking the device there to move to address $F.  The handler ID field is $FE, indicating that a device should not move if it has detected a collision.
7) Both Fred and Wilma receive the request.
8) Fred moves to address $F; however, Wilma does not, as she has been locked out of moving because she detected a collision while responding to her last talk register 3 command.
9) The host sends a talk register 3 to address $F to ensure that a device moved there.  Fred responds, assuring the host he has moved.
10) The host repeats the separation procedure, sending a talk register 3 to address 3, followed by a listen register 3 to address 3 asking the device there to move to address $E.
11) This time, Wilma does not detect a collision, as she is the only device remaining at address 3, so she moves to address $E.
12) The host sends yet another talk register 3 to address 3, but does not receive a response, as there are no more devices remaining at address 3.
13) The host relocates Wilma from address $E back to address 3 with a listen register 3 command sent to address $E.
    14) The host moves on and repeats the process for address 4.
Each and every ADB controller isn't guaranteed to follow this procedure precisely, but it gives a feeling for the principle behind the address resolution process.  You may see some implementations moving devices many more times than is necessary; this is done because some devices have been manufactured to tolerances close enough that not only do they send their bits at exactly the same time and so cannot detect collisions with each other, but they select the same random numbers to transmit.  We recommend that you include some low tolerance device (such as a capacitor on your reset line) to ensure that various devices will respond differently and be able to detect their collisions with each other.
Autopolling
Autopolling is the primary method via which the host fetches data from your device.  The basic mechanism is that the host repeatedly issues talk register 0 commands to your device; if your device responds with data, it is passed to your device's driver, which should act on it as new data.
This implies that register 0 should be the primary data transfer register for most devices; registers 1 and 2 are usually only used for supplementary data to configure the device.  Most device drivers have no need to issue commands to their device, as all necessary data has been transferred within register 0.
When a device wishes to transmit data, it should wait until a command is issued to it or some other device.  If, when this transmission is completing, it still wishes to transfer data (if the command was sent to our device, it might have fetched the data already,) it should assert SRQ after the data portion of the command by holding the bus low for 300 µs after the stop bit.  This will alert the host that some device wishes to transmit data.  It will then begin polling those addresses which it knows hold devices.  If a device does not have any data, the host will move on to the next address, asking each device in turn, until SRQ is no longer asserted, indicating that all pending data has been fetched.
When an SRQ is not asserted, the host will continually poll the last device to send it data, sending it talk register 0 commands periodically.  This is done under the assumption that this is likely to be the next place the user interacts; if the user types a character, she is very likely to type another soon.  On current hosts, this can happen up to 150 times a second, although it can happen much less frequently in some cases. If the device responds with any data, the host will call the device's driver with the data.
Your device should only respond with data when sent a talk register 0 command if it has new data. If the status of the device has not changed since the last talk register 0, then it should not respond at all, allowing the bus to time out. This is useful for two reasons: first, it tends to reduce the demands on the host, as your driver need not be called when your device has nothing useful to say. Second, in some ADB implementations, the host can get "hung up" on your device if you always respond. For example, say that you have a device at address 4 which will always respond, regardless of whether it has new data, there is another device at address 7, and the system is currently autopolling address 2. If the device at address 7 asserts SRQ, the system will begin looking through the addresses looking for the device which has data to send.  When it reaches your device at address 4, your device will respond, although it has nothing new to say. On some implementations, this will cause the host to repeatedly ask your device for more data, and your device will continue responding. Meanwhile, device 7 is withering away at the end of the bus and will never get serviced. What your device should do is not respond to the talk register 0, as it has no new data; this will allow all host implementations to pass you by and reach the device at address 7 which needs the host's attention.
A useful summary of a reasonable algorithm is:
•    Wait for a command to begin
•    If the command is directed to my address, handle it.  If it is a talk register 0 command, only respond if there is new data waiting to be sent.
•    At the end of the command, if there is data waiting to be sent, assert SRQ, regardless of who the original command was directed towards.
This simple behavior will produce the appropriate responses and SRQ generation for proper bus functioning.  It shouldn't be necessary for your device to explicitly have any knowledge of whether it is the "active" device or not; a robust basic behavior will eliminate any need for such information.
As an optimization, all recent versions of the ADB manager will not automatically poll a device which does not have a driver service routine installed.  In this case, they will switch to autopolling some other device, even if that device has not been recently communicated with.  However, the host may poll a device, even if it does not have a service request, in order to try to clear an SRQ on the bus.
Bus Initialization
Bus initialization doesn't work exactly as it might seem from looking at some documentation.  A SendReset command is never sent to individual devices; rather, when a bus reset is requested, the ADB manager sends a SendReset command which is broadcast to all devices, causing them to reset themselves and go to their default addresses and handler IDs.  The relocation and driver loading procedure will follow immediately after the reset command is sent.
ADB Drivers
Driver Installation
In the past, the recommended way to install an ADB driver was to install a resource of type 'ADBS' with the same resource ID as your device's default address in the system file which held code to install the driver for the ADB driver, along with the driver itself.  When the system was booted or when the bus was reinitialized, the system would get the 'ADBS'resource and execute it, which would let your code set the driver for that device up.  Unfortunately, this system is not well designed for the wide variety of devices available; the most prominent flaw is that the 'ADBS'resources are indexed by default address only; thus, there is no way to use the 'ADBS'mechanism to load drivers for two different devices at address 7, as there can be only one resource with ID 7.  A further flaw is that it requires installation into the system file, which is not currently recommended for a number of reasons.  In any case, it has always required a special installation and deinstallation program and has been more than a little confusing for users.
Currently, the recommended method is to supply the user with a system extension which will load your driver; this can either be a simple extension, or it can be contained within a control panel, should your device require some user interface for configuration.  Your code, when loaded, should look for your device and install your driver for it. If your device is at a default address which is not shared with standard Apple devices, you don't have to concerned with what driver is installed for you by default; your device can just power up at its standard address with its handler ID.  Your extension can then locate your device's current address by indexing through all the known devices with the ADB manager call GetADBInfo(); when you find a device whose initial address and handler ID match your device's, you can call SetADBInfo() to install your driver's completion routine to handle autopolled data from your device.
Because your ADB driver is in a system extension which will not load until well into the system startup process, if your device is a standard one (a pointing device or keyboard) you might need to provide standard system functionality before your driver loads in order to allow the user to interact with the system during the startup process.  This also allows the user to use your device to control their machine even if they don't have the software installed, such as when they are booting off of a floppy.  In this case, your device will need to be able to emulate the Apple protocol for mouse or keyboard devices until your software driver loads, as discussed above in "Default Addresses and Handler IDs".  Until your driver is installed, your device will be serviced by the default driver for this address; this means that if your device is at address 2 or 3, even if it cannot emulate an Apple device, it must supply harmless data in register 0 until your driver loads and is installed, as the Apple ADB driver for that address may inadvertantly receive the contents of your register 0 and attempt to use it as input data.  If the data in your field caused effects such as the mouse button or shift key sticking down, this could cause problems for the user.
If you use the recommended procedure for handler IDs in this case, powering up with the appropriate Apple handler ID and switching to your custom ID when your driver loads, you will need to use ADB commands to find your device at startup.  You should index through the connected ADB devices with GetADBInfo() and if you find a device which has an original address and handler ID which indicates that it might be your device, attempt to switch it to your handler ID by using ADBOp() to send it a listen register 3 to change its handler ID.  (You will first need to read its register 3 with a talk register 3 command so you can correctly copy the various flag bits in the register you send to the device.)  You should then issue a talk register 3 command to the device and examine the response to see if the new handler ID was accepted and reported back by the device; if so, you can be certain that this device is your device and you can then call SetADBInfo() to install your driver as the handler for that device.
In the original method using 'ADBS' resources, the system could automatically reload your driver any time the bus was reinitialized.  If your driver is loaded via a system extension there isn't any way for the system to find your device and driver and reconnect them after the bus is reinitialized and devices are relocated.  Thus, you've got to manually reconnect your driver to your device each time the bus is reinitialized.  Fortunately, there is a system provision for you to be notified each time the bus is reinitialized; there is a low memory global called jADBProc (at address $6B8) which is a pointer to a procedure to be called just before and just after the bus is initialized.  When the procedure is called before the bus is initialized, register D0 is set to 0; after, it is set to 1.  When your extension loads and installs your driver, you should remember the value in the jADBProc global and then install a pointer to a procedure of your own in that location; when this procedure is called, it should do its thing, then call through to the next procedure in the chain, whose address was in jADBProc before you replaced it (if jADBProc was equal to 0 before you installed, just return from your procedure).  Don't forget to preserve register D0 so subsequent procedures can tell if they are being called before or after the reinitialization.  The actions you take in the post-initialization case should basically duplicate your original installation procedure, including looking through all the devices for devices of your type and calling SetADBInfo() to install your driver for your devices.
For history buffs, this is the second time we've changed our recommended procedure for loading ADB drivers.  Initially, it was recommended that ADB drivers be loaded with INITs; however, at the time, jADBProc did not exist, so when the Macintosh Portable came out, INIT-handled devices had the fatal flaw of not reloading their drivers when the Macintosh was put to sleep and reawakened, since this procedure involved resetting the bus.  This cause us to begin recommending the use of the 'ADBS'resource, since in this way the driver could be reloaded from the System file.  However, the 'ADBS'approach has so many major flaws that we have stopped recommending it now that the jADBProc global has been introduced.  As far as I can tell, jADBProc has been available at least since System 6.0.4.
For true history buffs, or possibly for specialized applications, here is the description of the 'ADBS'resource functionality: the 'ADBS'resource is loaded into the system heap by the system and detached with DetachResource().  The resource is then called by JSRing to the first byte of the resource. At this time, the registers are set up as follows: A0 holds the address of the 'ADBS'resource data (although it is no longer in a resource handle, thanks to the DetachResource() call); if a handle to the resource is needed, RecoverHandle() can be called to retrieve it.  The low byte of register D0 holds the ADB device's current address (due to relocation, this might not be the same as the default address) and the low byte of register D1 holds the handler ID of the device in question.
The Cursor Device Manager
In order to be able to manage an expanding set of relative movement devices, Apple has created the Cursor Device Manager, which is a software architecture which provides a standard interface to devices of widely varying resolutions and capabilities.  This also allows better management of multiple relative devices on a single bus; in the old architecture, all connected devices shared a single button state and acceleration curve, which became a problem for Apple and for third-party device manufacturers.  The Cursor Device Manager provides a number of calls for finding, configuring, and manipulating relative devices connected to the bus.  It also supports the new extended mouse protocol, which is described below in the "Apple Devices" section.
Cursor Device Manager types
The Cursor Device Manager treats each relative or absolute device as a "Cursor Device".  Each one is specified by a CrsrDevRec which is defined as follows:
CrsrDevPtr = ^CrsrDevRec;
CrsrDevRec = RECORD
    nextCrsrDev    :CrsrDevRec^    ; ptr to next record in linked list
    whichCursor    :CrsrDataRec^    ; ptr to data for target cursor
    refCon    :LongInt    ; Application defined
    unused    :LongInt    ; reserved for future
    devID    :OSType    ; device identifier(from ADB reg 1)
    resolution    :Fixed    ; units/inch (orig. from ADB reg 1)
    devClass    :Char    ; device class     (from ADB reg 1)
    cntButtons    :Char    ; # of buttons     (from ADB reg 1)
    spare1    :Char    ; reserved
    buttons    :Char    ; state of all buttons
    buttonOp    :Array[0..8] of Char    ; action performed per button
    buttonTicks    :Array[0..8] of LongInt    ; ticks when button last went up        buttonData    :Array[0..8] of LongInt    ; data for the button operation
    doubleClickTime    :LongInt    ; device’s double click time
    acceleration    :Fixed    ; current acceleration
    accelPoints    :Ptr    ; Private: Ptr to array of  (dev_delta,
            ;     slope, intercept)
    deltaX    :Fixed    ; Private: accumulated deltas
    deltaY    :Fixed    ; Private:         "
    errorX    :Fixed    ; Private: accumulated errors
    errorY    :Fixed    ; Private:         "
    denom    :Fixed    ; Private: fraction of the errors to
            ;     use next time
    spread    :Fixed    ; Private: Number of samples to spread
            ;     errors over
    newData    :Char    ; Private: set when deltas are new
    spare2    :Char    ; reserved
END;
The cursor controlled by this cursor device is described with a CrsrDataRec:
CrsrDataPtr = ^CrsrDataRec;
CrsrDataRec    = RECORD
    nextCrsrData    :CrsrDataRec^    ; next in global list
    displayInfo    :Ptr    ; reserved for future use
    whereX    :Fixed    ; horizontal position
    whereY    :Fixed    ; vertical position
    where    :Point    ; the pixel position
    isAbs    :Boolean    ; has been stuffed with absolute coords
    buttonCount    :Char    ; number of buttons currently pressed
    screenRes    :Integer    ; Pixels per inch on the current display
END;
Most of the fields are fairly self-explanatory.  The fields labeled as private at the end of the CrsrDevRec are used to manage cursor acceleration and shouldn't be modified by your software.  Some of the usage of the other fields will be explained below in the description of the cursor device manager routines.
Cursor Device Manager Routines
CrsrDevNextDevice:
Function CrsrDevNextDevice(VAR curDevice: CrsrDevPtr):OSErr;
CrsrDevNextDevice() can be used to index through the various devices the Cursor Device Manager is aware of.  You pass it a CrsrDevPtr; initialize this variable to nil to advance to the first device in the list, then call CrsrDevNextDevice() repeatedly, each time passing the CrsrDevPtr as it was last modified; when you have reached the end of the device list, the pointer returned in the curDevice parameter will be 0.
CrsrDevNewDevice:
Function CrsrDevNewDevice(VAR ourDevice: CrsrDevPtr):OSErr;
Call CrsrDevNewDevice() to create a new cursor device and link it into the device chain. The new device record will be initialized with values representing a standard one-button mouse; you should call CrsrDevSetAcceleration() for the device after creating it. A pointer to the created device is returned in the ourDevice variable.
New cursor devices are created for all ADB address 3 devices. This routine should only be needed by devices which are connected though some other method, such as the serial port.
CrsrDevDisposeDevice:
Function CrsrDevDisposeDevice(ourDevice: CrsrDevRec):OSErr;
This routine disposes of a cursor device and unlinks it from the device chain.  This isn't needed by most developers, but could be useful for non-ADB devices which might be connected and disconnected.
CrsrDevMove:
Function CrsrDevMove(ourDevice: CrsrDevRec;
                     deltaX,deltaY: LongInt):OSErr;
CrsrDevMove() accumulates the deltaX and deltaY values into the recorded movement of the device; the next time the cursor position is calculated, these deltas will be fed through the acceleration algorithm and used to move the cursor.  This routine should be called by a relative device driver with the data it receives from its device, even if the deltas are both zero; this lets the acceleration algorithm properly calculate the appropriate motion.  This routine is automatically called by the default driver for address 3 devices; you would only need to call it if you were using a custom driver.
CrsrDevMoveTo:
Function CrsrDevMoveTo(ourDevice: CrsrDevRec;
                       absX,absY: LongInt):OSErr;
CrsrDevMoveTo() sets the absolute position of the cursor to (absX, absY).  The next time the cursor position is calculated, it will be moved to this absolute location.  This would normally be used by a driver for an absolute pointing device to position the cursor.
CrsrDevFlush:
Function CrsrDevFlush(ourDevice: CrsrDevRec):OSErr;
CrsrDevFlush() causes the acceleration and motion algorithms to flush out all their error collection and motion deltas into the cursor position; it indicates that your device is done moving temporarily.  This may be useful for devices which can tell when they become idle (such as a stylus pointing device); if they call this routine when they become idle, it ensures that all unused motion data will be worked into the cursor position at the next time it is calculated.
CrsrDevButtons:
Function CrsrDevButtons(ourDevice: CrsrDevRec;
                        buttons: Char):OSErr;
CrsrDevButtons() handles posting mouseUp and mouseDown events and also deals with debouncing mouse clicks.  Pass the current button status in the buttons parameter, going from bit 0 is button 0 to bit 7 representing button 7.  For each button, a one bit represents down, a zero bit represents up.  This routine debounces mouse clicks to keep them from looking like double clicks; if the button goes down less than 2 ticks after coming up, then the mouseDown will be ignored. Button up events are never ignored to avoid problems such as continuous scrolling which are confusing and difficult for the user to deal with.  A device driver should call this routine any time it gets a data packet; this routine deals with keeping track of whether the button state has changed.  This routine automatically calls routines installed with CrsrDevButtonOp().
CrsrDevButtonDown:
Function CrsrDevButtonDown(ourDevice: CrsrDevRec):OSErr;
CrsrDevButtonDown() posts a mouseDown event if this is the first button to go down for this device.  It is called by the standard button operation routines; you should need to call it only if you use a custom button operation routine.
CrsrDevButtonUp:
Function CrsrDevButtonUp(ourDevice: CrsrDevRec):OSErr;
CrsrDevButtonUp() posts a mouseUp event if this is the last button to come up for this device.  It is called by the standard button operation routines; you should need to call it only if you use a custom button operation routine.
CrsrDevButtonOp:
Function CrsrDevButtonOp(ourDevice: CrsrDevRec; btnNo: Integer;
                         opCode: Integer; data: LongInt):OSErr;
CrsrDevButtonOp() sets a new operation to be associated with a particular button.  btnNo may range from 0 to 7, and opCode specifies what operation to use.  The data field specifies a parameter for the operation you are setting for the kButtonCustom operation.  The opCode parameter may have one of the following values:
kButtonNoOp    No action
kButtonSingleClick    Normal mouse button
kButtonDoubleClick    Click, release, and click again when pressed
kButtonClickLock    Click on press, release on next press
kButtonCharStroke    Unimplemented, reserved
kButtonAppleScript    Unimplemented, reserved
kButtonCustom    Call a custom procedure; data holds its address

Using the btnCustom operation will cause a procedure whose address is passed in data to be called whenever this button changes state.  The procedure takes the following parameters: the address of the CrsrDevRec record for its device is passed in register A2; the button being pressed or released is in register D3.  The new state of the button will already have been filled into the buttons field in the CrsrDevRec, so you may use that flag to determine if the button is being clicked or released.  Your routine may destroy registers D0, D2, A0 and A1; it must preserve all other registers.
The kButtonCharStroke and kButtonAppleScript operations are currently unimplemented and will simply cause the button press to be ignored.
CrsrDevSetButtons:
Function CrsrDevSetButtons(ourDevice: CrsrDevRec;
                           numButtons: Integer):OSErr;
CrsrDevSetButtons() allows you to set the number of buttons on the device specified by ourDevice to numButtons.
CrsrDevSetAcceleration:
Function CrsrDevSetAcceleration(ourDevice: CrsrDevRec,
                               acceleration: Fixed):OSErr;
CrsrDevSetAcceleration() lets you set the acceleration for the device specified by ourDevice to the value specified by acceleration, where 0 ≤ acceleration ≤ 1.  The Cursor Device Manager will build an acceleration table for the device based on its device ID or device class and the desired acceleration value.  For details on acceleration resources, see "Acceleration Tables" below.  The acceleration table set by CrsrDevSetAcceleration() is found by interpolating the tables stored in the appropriate acceleration resource.  All 'accl' resources in the resource chain or in the ROM are searched looking for the one applying to the specified device, so a control panel which called CrsrDevSetAcceleration() could implicitly use 'accl' resources stored within the control panel's resource fork.
CrsrDevDoubleTime:
Function CrsrDevDoubleTime(ourDevice: CrsrDevRec;
                           duration: LongInt):OSErr;
CrsrDevDoubleTime() lets you set the double-click time associated with a particular device.  The duration parameter specifies the time, in ticks, to use as the double-click time for this device.  An application could be written to check the double-click time for the particular device in checking for a double-click.
CrsrDevUnitsPerInch:
Function CrsrDevUnitsPerInch(ourDevice: CrsrDevRec;
                             resolution: Fixed):OSErr;
CrsrDevUnitsPerInch() lets you set the resolution of a particular device to its physical resolution, in units per inch.  For devices adhering to the Apple extended mouse protocol, this call shouldn't  be needed, as the resolution can be read from the device's register 1; however, this call might be made by a driver for a device which doesn't use the ADB.
Acceleration Tables
Acceleration tables are stored in resources of type 'accl', which have the following Rez description:
type 'accl' {
    literal longInt    /* Device identifier or device class     */
        classAbsolute,    /* A flat-response device     */
        classMouse,    /* Mechanical or optical mouse     */
        classTrackball;    /* Trackball     */

    integer = $$CountOf(AcclTable);    /* Number of tables for this device    */
    array AcclTable {    /* Entries sorted by first value; must have    */                /* at least 0.0 and 1.0 tables    */
        unsigned hex longint;    /* Acceleration provided by this table (Fixed) */

        integer = $$CountOf(AcclPoint);    /* Number of control points for this device    */
        wide array AcclPoint {    /* Entries sorted by first value; implicit     */
                /* first entry (0.0, 0.0); at least one more    */
                /* entry required.     */
            unsigned hex longint;    /* Device speed (inches per second) (Fixed)     */
            unsigned hex longint;    /* Cursor speed (inches per second) (Fixed)     */
        };
    };
};
The identifier for this 'accl' resource is stored in the first long word; this is either an OSType four character device identifier or an integer value specifying the device class. In either case, the device's identity is generally read from the device's register 1, as described below in the section "Extended Apple Mouse Protocol." The Cursor Device Manager first tries to match against the specific device identifier, then against the more general class.  Each 'accl' resource can contain a number of acceleration tables for different acceleration values; each table contains a number of entries which match a particular device speed to a particular cursor speed.  An 'accl' resource must contain at least two acceleration tables, one for an acceleration of 0.0 and one for an acceleration value of 1.0.  When an acceleration value is set for a particular device, the acceleration table is calculated by interpolating between the two nearest tables from the 'accl' resource.  There is an implicit entry in each acceleration table of (0.0, 0.0), which indicates that the cursor should not move if the device does not.  At least one additional entry is required; the Cursor Device Manager will use the table entries to figure the cursor movement by using the device movement to interpolate based on the specified movement control points.
Availability Of The Cursor Device Manager
The Cursor Device Manager was introduced in the ROMs of Macintoshes introduced in February, 1993.  It may be installed via software on any Macintosh.  To check to see if the Cursor Device Manager is available, you should use the standard TrapAvailable routine to check to see if its trap is implemented.  The Cursor Device Manager trap is $AADB, making it a toolbox trap, trap number $2DB.
Compatibility
When the Cursor Device Manager is installed, all Apple mouse drivers use its interface to move the cursor; this means that the low memory globals such as Mouse and RawMouse are no longer used.  While a compatibility mode keeps drivers which still modify these globals continue to work, the cursor position can no longer be read from these globals.
Apple Devices
Classic Apple Mouse Protocol
The original Apple mouse protocol has allowed for mice with a resolution of 100 or 200 units per inch with 7 bit accumulation of relative movement with one or two buttons. Handler ID 1 was used to indicate 100 cpi operation; handler 2 to indicate 200 cpi operation. All data is transferred through register 0 in the following format:
Figure 1–Classic Mouse Register 0 Format
Where relative motion in each axis is accumulated until fetched with a talk register 0 command sent by the host. The X value represents left-to-right motion, the Y value holds accumulated forward-to-back motion.
Extended Apple Mouse Protocol
In order to be able to take advantage of the higher movement resolution support available with the Cursor Device Manager, an extended mouse protocol has been defined; this allows a device to communicate up to 16 bits of movement data with each polling and allows a standard device to communicate the state of up to 8 buttons. In addition, the new format allows each device to communicate its exact type, resolution and class. This new format applies to all relative devices at default address 3, handler ID 4.
During startup or after a reset of the ADB bus, devices which power up at default address 3 with handler ID 1 will be switched to handler ID 4 with a listen register 3 command.  If the device accepts the switch and reports the new handler ID of 4 back in response to a talk register 3 command, all subsequent communication with the device will be assumed to follow the extended mouse protocol.  Currently, the ADB manager makes an additional check, making sure that a talk register 1 returns 8 bytes (the format of register 1 is specified below).  If a device accepts a handler ID change but does not return 8 bytes from register 1, it is assumed to not actually be an extended mouse protocol device and is switched back to its original handler ID.
All movement and button data still passes through register 0, which can now hold between 2 and 5 bytes, where 2 bytes provides the device with the data transfer capability of the original mouse protocol and additional bytes allow added resolution and buttons.
Bytes 0 and 1 of register 0 have the same format as they did in the classic mouse protocol, communicating the state of the first two buttons and the low order 7 bits of the accumulated motion in the X and Y axes.  There can be up to 3 bytes of additional information: each one of these bytes can communicate the state of 2 more buttons and add 3 higher order bits of resolution to each of the X and Y axes. The format of each additional byte is:
Figure 2–Format Of Additional Register 0 Bytes For Extended Mouse Protocol
As a specific example, in a maximal 5 byte transmission, the data would be transferred in this format:
Bit #:    7    6    5    4    3    2    1    0
Byte 0:    b0    y06    y05    y04    y03    y02    y01    y00
Byte 1:    b1    x06    x05    x04    x03    x02    x01    x00
Byte 2:    b2    y09    y08    y07    b3    x09    x08    x07
Byte 3:    b4    y12    y11    y10    b5    x12    x11    x10
Byte 4:    b6    y15    y14    y13    b7    x15    x14    x13

Table 2–Format Of A 5 Byte Register 0 Data Transfer
Where bn indicates the status of button n and xaa or ybb indicates the value of bit aa or bb of the X or Y movement.
In addition, register 1 is used in the extended mouse protocol to provide some general information about the device.  Register 1 is 8 bytes long and is formatted in this way:
Byte range    Format
0-3    Unique device identifier
4-5    Device resolution in units/inch
6    Device class (Mouse, trackball, etc.…)
7    Number of buttons (0-8)

Table 3–Format Of Extended Mouse Protocol Register 1
The unique device identifier is intended to be a four character ASCII identifier similar to the OSType identifiers used as types and creators in the Macintosh file system; they can be registered using the same mechanism used to register creator types. A developer should only use a device identifier in this field if they have obtained a registration for that identifier's use as a creator from Apple.
The device class is a value which is used to identify the type of device and to control the acceleration curve used for that device.  The currently defined constants include:
Device constant    Device type
0    Tablet device (absolutely positioned)
1    Mouse
2    Trackball

Table 4–Currently defined device classes
There currently isn't any mechanism for developers to create or register device classes; if a developer needs a device class not available from Apple, the only alternative available currently is not to use the handler ID 4 extended mouse protocol, instead using a custom handler ID and custom driver software.
Apple Keyboard protocol
The Apple keyboards have a simple data transfer protocol.  Register 0 is used to inform the host as keys are depressed and released; register 2 is used to communicate the state of the modifier keys and to control the LED indicators on the extended keyboards.
The format of register 0 is:
Figure 3–Keyboard Register 0 Format
Register 0 can communicate up to two key transitions at once.  Each transition consists of a key code and a key released bit, which is 0 for key depressions and 1 for key releases.  The key codes are described in Inside Macintosh volume V, pages 191-192.  The special case is the reset key, which returns the value $7F7F in register 0 when it is depressed and $FFFF when released; thus, it uses both key code positions within register 0.
The format of register 2 is:
Figure 4–Keyboard Register 2 Format
The current state of the keys listed in figure 4 is available in bits 6-14 of register 2, if those keys exist on the keyboard being examined.  Bits 0-2 hold the current state of the LEDs on the extended keyboard; the states of these LEDs can be changed by sending the keyboard a listen register 2 command.  Note that key transition events are generated in register 0 for modifier keys, as they are for all other keys; these keys are available in register 2 in addition to their status being transmitted through register 0.
Miscellany
Licensing
The Apple Desktop Bus is patented.  In order to build an ADB device, you will need to get a license from Apple.  Contact:
Apple Software Licensing
Apple Computer, Inc.
20525 Mariani Avenue, M/S 38-I
Cupertino, CA       95014
[phone]
AppleLink: SW.LICENSE
Internet: [e-mail]
The license is available for a nominal fee in most cases, and the licensing package includes the latest version of the ADB spec., which is the definitive reference to the bus.
Further Reference:
•    The Apple Desktop Bus specification, revision F.
•    Inside Macintosh, Volume V, chapter 20, "The Apple Desktop Bus"
•    Guide to the Macintosh Family Hardware, Second Edition, Chapter 8, "Apple Desktop Bus"
xHRˇˇˇˇˇRH†Ç

/ZÅ#
    0Ià:µú9"{    ˇˇˇˇˇˇˇˇ#†ƒ°d
ONLNf
˛†å°d1drw2
…-
·
_ġˇˇˇˇˇ

è°ñ
x°ddrw2:
°ddrw2:$°d4drw2:





°öˇ˙ó@†ò,Times

.
R
…R
…+]BNew Technical Notes†ô°ddrw2:°„
†ó°d1drw2
e
Ùġˇˇˇˇˇ

P°ñ
x°ddrw2:
°ddrw2:$°d4drw2:




°öˇ˚ÄE¿†ò
({
ïDeveloper Support†ô°ddrw2:°„
†ó°d`drw2-
Ôˇˇˇˇˇˇ

K
Ô-
Z
 ffZ°d1drw2
 
¿
˙
Èˇˇˇˇˇˇ

K°ñ
x°ddrw2:
°ddrw2:$°d4drw2:
0



°öˇÙĆò
0(U
Ô
†ô°ddrw2:°„
†ó°d1drw2
Ô
Ê
˙
ˇˇˇˇˇˇ

°ñ
x°ddrw2:
°ddrw2:$°d4drw2:
    



°öˇ˝Ä†ò
    +&    
®†ô°ddrw2:°„
†ó°d1drw2
Â-
¯yˇˇˇˇˇˇ



°ñ
x°ddrw2:
°ddrw2:$°d4drw2:




°öˇ˚Ä%†ò
(Z\    Macintosh†ô°ddrw2:°„
†ó†ç°ddrw2D†É

HR
.



°dONLNdçZ†(õZ0ADB–The Untold Story : Space Aliens Ate My Mouse
°dONLNd1üZÆö*Hardware
°dONLNd;∫ZΔè*Written by:°dONLNdG∫¢Δ
)HTim Dierks, Jim Mensch°dONLNd^∫
‹Δ(√
‹January 1994°dONLNdkΔZ“õ(œZOriginally by:°dONLNdzΔ¢“
,)HCameron Birse, Rich Kubota°dONLNdïfiZÍ¢(ÁZThis Technical 
°dONLNd§fi¢Í)HJNote explains a number of esoteric and unknown issues concerning the Apple°dONLNdÔÍZˆ
∏(ÛZJDesktop Bus (ADB).  It incorporates material from the original version of 
°dONLNd
9Í
∏ˆ(Û
∏this note, along with°dONLNd
OˆZ
|(ˇZa large 
°dONLNd
Wˆ|
)"Vamount of new information, and is intended to detail information concerning all levels°dONLNd
Æ
Z
g(
Zof 
°dONLNd
±
g
)
Ythe ADB, from the hardware to the application usage level.  This note is supplementary to°dONLNd
Z
¥(
Zthe information in °dONLNd
¥

Ö)Z&The Guide To Macintosh Family Hardware°dONLNdD

Ö

Ω)— and in the °dONLNdP

Ω

›)8Apple °dONLNdV

›
) Desktop Bus°dONLNdb
Z
&ó(
#Z
Specification°dONLNdo
ó
&
Ó)=F. The information in the specification is the most accurate source of °dONLNdµ

Ó
&(
#
Ó    data, and°dONLNdø
&Z
2
…(
/ZTunless it is specifically refuted, it should be treated as the authoritative source.

°dONLNd
2Z
>è*Changes °dONLNd
2è
>
)5since October 1991:°dONLNd/
2

>)u7  This note has been rewritten; new information appears

"
2
°dONLNdg
>Z
J(
GZXthroughout the document.  In particular, the Cursor Device Manager is discussed in this °dONLNdø
>
J(
Gnote"
>°dONLNdƒ
JZ
V
Ì(
SZUfor the first time. The information regarding bugs fixed in System 6.0.4 was omitted."
J
°dONLNd
bZ
nÄ*Topics°dONLNd!
nu
zy+
•°dONLNd#
n~
z
2)    #A discussion of ADB hardware issues°dONLNdG
zu
Üy(
Éu
•°dONLNdI
z~
Ü
ÿ)    EInformation on the ADB protocol, including a detailed description of °dONLNdé
z
ÿ
Ü
Ê(
É
ÿthe°dONLNdí
Ü~
í
9(
è~&relocation and autopolling mechanisms.°dONLNdπ
íu
ûy(
õu
•°dONLNdª
í~
û
x)    1The recommended method of ADB driver installation°dONLNdÌ
ûu
™y(
ßu
•°dONLNdÔ
û~
™
Z)    +Documentation for the Cursor Device Manager°dONLNd
™u
∂y(
≥u
•°dONLNd
™~
∂
∑)    @Description of the data formats used by Apple mice and keyboards°dONLNd^
∂u
¬y(
øu
•°dONLNd`
∂~
¬ˇ)    How to get an ADB license 
ŒX
Œ

°dONLNdz
ÁZ
ˆ›(
ÛZThe ADB Hardware
°dONLNdãZä*The ADB 
°dONLNdìä)0Ris a simple serial bus with collision detection.  A common implementation platform°dONLNdÊZ
é(Z?for the protocol is a simple microcontroller; a 2 MHz Motorola °dONLNd%
é(
é68HC11 has been used with°dONLNd?Z&
I(#Z1success, although any number of microcontrollers 
°dONLNdp
I&)Ô)would do a more than adequate job.  The 2°dONLNdö&Z2
•(/ZCMHz clock seemed to be close to minimal for this application.  The °dONLNd›&
•2(/
•bus has a relatively low
°dONLNdˆ2Z>
·(;ZObandwidth; given the packet structure, the theoretical maximum bandwidth is on °dONLNdE2
·>(;
·the order of
°dONLNdR>ZJ
8(GZ.100 - 200 bytes/second.  In practice, the bus °dONLNdÄ>
8J)fi2is not suitable for data transfer applications; it°dONLNd≥JZV
˝(SZZserves well as a general purpose input device bus, but high data rates will not work well.°dONLNdbZn°*In general, the 
°dONLNdb°n)GNtiming for the ADB is fairly tolerant of small variances; however, many recent°dONLNdmnZz(wZXMacintoshes are more demanding than their predecessors. For this reason, devices should °dONLNd≈nz(wbe°dONLNd»zZÜ
ì(ÉZDtested on a wide range of machines; the best test for compliance is 
°dONLNd    z
ìÜ(É
ìtesting.  Specifically, the Tlt°dONLNd    ,ÜZí
;(èZ/(stop to start time) parameter has become much 
°dONLNd    [Ü
;í)·1less tolerant in recent Macintoshes; fairly close°dONLNd    çíZû
m(õZ=adherence to its 200 µs timing is important.  In particular, 
°dONLNd     í
mû(õ
m"devices which respond more rapidly°dONLNd    ÌûZ™
ñ(ßZEthan the 140 µs minimum delay will often fail to initialize properly. ¿X¿

*.9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse(’
ˇ
1) of 18(ÎZHardwareˇ°¿
Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
†ø*HRˇˇˇˇˇRH

HR,Times

.+6-Macintosh Technical Notes /4/
˘
°dONLNdH6T…*$!It is important that your device 
°dONLNd!H…T
¯)ì>be fairly tolerant of problems on the bus; if a command packet°dONLNd`T6`á(]6begins but never 
°dONLNdqTá`
¯)QKseems to complete, your device should time out rather than hang; the design°dONLNdΩ`6l
0(i66of the bus and its connectors means that there can be 
°dONLNdÛ`
0l
¯)˙*occasional glitches in the connection with°dONLNd
l6x
k(u6Dthe host, and you should try to be as tolerant of these as possible.°dONLNd
dÑ6êÙ*'Because the ADB bus is open collector, 
°dONLNd
ãÑÙê
¯)æ6collisions can be detected when a device is attempting°dONLNd
¬ê6úÆ(ô6to drive the bus high and 
°dONLNd
‹êÆú
¯)xDanother device pulls it low.  This means that whenever the device is°dONLNd!ú6®
u(•6Adriving the bus high, it should be watching to make sure the bus °dONLNdbú
u®
¯(•
uis actually high; if the bus°dONLNd®6¥À(±6goes low, some other device is 
°dONLNdû®À¥
¯)ï?sending at the same time. When a device detects a collision, it°dONLNdfi¥6¿
3(Ω66should immediately stop transmitting; this means that 
°dONLNd¥
3¿
¯)˝)if two devices are colliding, one of them°dONLNd>¿6Ã
ò(…6Iwill detect the collision, while one will not.  This is because a device °dONLNdá¿
òÃ
¯(…
òcan only detect the°dONLNdõÃ6ÿ
‹(’6^collision if it is driving the bus high and another device drives it low.  The device driving 
°dONLNd˘Ã
‹ÿ
¯(’
‹it low°dONLNdÿ6‰{(·6has no way to 
°dONLNdÿ{‰
¯)EStell that there was a collision, as the bus follows it.  Since the detecting device°dONLNdb‰6
p(Ì6Eimmediately stops transmitting, the other device will not detect the 
°dONLNd߉
p
¯(Ì
pcollision.  Thus, if there are°dONLNdΔ6¸>(˘6a 
°dONLNd»>¸
¯)Znumber of devices transmitting on the bus, only one of them will complete its transmission°dONLNd#¸6
÷(
6!without detecting the collision, °dONLNdD¸÷

¯)†6unless the unlikely occurrence of more than one device°dONLNd{
6


(
6(transmitting exactly the same data with °dONLNd£




¯)À/the same timing occurs, and neither detects the°dONLNd”
6
 b(
6
collision.°dONLNdfi
,6
8
∑*QThe ADB is not particularly tolerant of devices being connected and disconnected 
°dONLNd/
,
∑
8
¯(
5
∑
while the bus°dONLNd=
86
D
D(
A69is live. There isn't any software architecture to detect °dONLNdv
8
D
D
¯(
A
D"the presence of new devices or the°dONLNdô
D6
PÁ(
M6%absence of old ones; furthermore, on 
°dONLNdæ
DÁ
P
¯)±5some CPUs, the motherboard is not well protected from°dONLNdÙ
P6
\
;(
Y67voltage transients on the ADB connector; plugging in a 
°dONLNd+
P
;
\
¯(
Y
;&device while the Macintosh is on could°dONLNdR
\6
h
¿(
e6Scause damage to the ADB transceiver or other portions of the Macintosh's circuitry.
°dONLNd¶
t6
Ä
Ô*\On some portable Macintoshes, the voltage characteristics are not exactly what is specified °dONLNd
t
Ô
Ä
¯(
}
Ôin°dONLNd
Ä6
å
(
â6/the ADB spec.  Clearly, power is very valuable 
°dONLNd4
Ä

å
¯)‚/on all portable computers, so if your device is°dONLNdd
å6
òb(
ï6    targeted °dONLNdm
åb
ò
¯),Htowards portable use, you should be extremely careful to keep your power
°dONLNd∂
ò6
§
(
°6*consumption as low as possible; while the °dONLNd‡
ò

§
¯)—0ADB can supply the full voltage specified in the°dONLNd    
§6
∞
£(
≠6Dspec., drawing this much power will lead to much more rapid battery °dONLNd    U
§
£
∞
¯(
≠
£draining. On the°dONLNd    f
∞6
º˙(
π6#PowerBook 140 and 170, there was a °dONLNd    â
∞˙
º
¯)ƒ1specific problem which caused the low-level input°dONLNd    ª
º6
»
(
≈6-voltage to go above the specified maximum of 
°dONLNd    Ë
º

»
¯)‹/0.8 volts; it commonly came close to 1.5 volts.°dONLNd

»6
‘
°(
—6MThis has caused problems for some third-party devices; it has been corrected 
°dONLNd
e
»
°
‘
¯(
—
°on all more recent°dONLNd
x
‘6
‡
F(
›67machines. There is a recommended service procedure for 
°dONLNd
Ø
‘
F
‡
¯(
›
F%repairing this problem available from°dONLNd
’
‡6
Ï
p(
È6CApple Service representatives, should this be a problem for a user.
°dONLNd
¯6v*
Soft Power°dONLNd$6
÷*SOn Macintoshes with software power control, the machine can be turned on by an ADB 
°dONLNdw
÷
¯(
÷device.°dONLNdÄ6(
Z(%6<This is accomplished by momentarily connecting pin 2 on the 
°dONLNdº
Z(
¯(%
ZADB connector (reserved) to pin°dONLNd‹(64Ü(164 (ground).  Pin 
°dONLNdÌ(Ü4
¯)PK2 should be kept grounded until pin 3 (+5 volts) comes up to power, letting°dONLNd946@∏(=6you know that the machine 
°dONLNdS4∏@
¯)Ç>has actually come on.  Some Macintoshes do not have soft power°dONLNdí@6L
w(I6Ecapabilities; on these machines, grounding pin 2 will have no effect.

°dONLNdÿX6g≤*The ADB Protocol
°dONLNdÈs6k*    Registers°dONLNdÛã6ó
Ü*HEach ADB device has four logical registers; the host can ask the device 
°dONLNd
;ã
Üó
¯(î
Üto talk or listen on each°dONLNd
Uó6£§(†6one of these registers; °dONLNd
mó§£
¯)nCa talk command asks the device to output the stored value from that°dONLNd
±£6ØÉ(¨6register; a listen 
°dONLNd
ƒ£ÉØ
¯)MMcommands asks the device to accept a new value for that register.  A register ¿4¿
˘

(’6
2) of 18)∫9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse+flHardwareˇBHRˇˇˇˇˇRH

HR,Times

.+Z-Developer Technical Support(-
ÁJanuary 1994 /X/
°dONLNd<ZH
l(EZ:can contain between 2 and 8 bytes.  Some of the registers 
°dONLNd:<
lH(E
l%have predefined functions: register 0°dONLNd`HZT⁄(QZis used as the primary data 
°dONLNd|H⁄T)ÄGtransfer register for most devices; it is this register which is polled°dONLNdƒTZ`z(]Zby the 
°dONLNdÀTz`) Winput mechanism (as described below).  Register 1 has no specified use; it is available°dONLNd
#`Zl
J(iZ2for any use the device might require.  Register 2 °dONLNd
U`
Jl)*has no specified use for most devices; the°dONLNd
ÄlZx
,(uZ+ADB specification does define an "extended 
°dONLNd
´l
,x)“2address device" protocol for register 2 on devices°dONLNd
fixZÑ
(ÅZ?at address 1, but this is unused by most developers.  Register 
°dONLNdx
Ñ(Å
!3 is used to identify devices and°dONLNd?ÑZê
£(çZ@to separate devices which occupy the same address, as discussed °dONLNdÑ
£ê(ç
£in "Address Resolution"°dONLNdóêZú{(ôZbelow.
°dONLNdû®Z¥
*!Default addresses and handler IDs
°dONLNd¿¿ZÃ
‚*REach ADB device identifies its software interface with two constants; the default °dONLNd¿
‚Ã(…
‚address and°dONLNdÃZÿß(’Zthe handler ID.  
°dONLNd/Ãßÿ)MPThis pair uniquely identifies a device's software interface; the default address°dONLNdÄÿZ‰
æ(·ZLusually specifies a device's general type (such as relative pointing device °dONLNdÃÿ
æ‰(·
æor keyboard) while°dONLNdfl‰Zk(ÌZthe 
°dONLNd„‰k)Zhandler ID specified the particular data protocol this device uses for communication.  The°dONLNd>Z¸
(˘Z*default address categories are as follows:
°dONLNdi
»
Ò+nDefault°dONLNdq
Δ
 Ù(
ΔAddress°dONLNdz

1
 
w)kDevice Type"
 ¡5"
˜"
 ˜ 
 ¯
 
Æ°dONLNdá
!⁄
-‡(
*⁄
1°dONLNdâ
!¸
-
Y)"Security & Dongles"
 ¡5"
 ˜ 
 ¯
 
Æ"
!˜°dONLNdù
-⁄
9‡(
6⁄
2°dONLNdü
-¸
9
0)"    Keyboards"
-˜°dONLNd™
9⁄
E‡(
B⁄
3°dONLNd¨
9¸
E
ì)" Relative pointing devices (mice)"
9˜°dONLNdŒ
E⁄
Q‡(
N⁄
4°dONLNd–
E¸
Q
ü)"#Absolute pointing devices (tablets)"
E˜°dONLNdı
Q⁄
]‡(
Z⁄
5°dONLNd˜
Q¸
]
ì)"Low speed data transfer devices"
Q˜°dONLNd
]⁄
i‡(
f⁄
6°dONLNd
]¸
i
©)" Reserved (PowerBook Duo charger)"
]˜°dONLNd<
i⁄
u‡(
r⁄
7°dONLNd>
i¸
u
®)"$Appliances (Miscellaneous catch-all)"
i˜
°dONLNde
Åÿ
ç
û(
äÿ"Table 1–Default address categories°dONLNdà
ôZ
•í(
¢ZThe default 
°dONLNdî
ôí
•)8Raddress is only a guide; there's no real reason a mouse can't be at address 7, but°dONLNdÁ
•Z
±
n(
ÆZ:default addresses are assigned on a category basis to try °dONLNd!
•
n
±(
Æ
n"to avoid the case where a user has
°dONLNdD
±Z
Ω
j(
∫Z9more than one device at a particular address; by putting °dONLNd}
±
j
Ω(
∫
j&all the relative devices at address 3,°dONLNd§
ΩZ
…
î(
ΔZDcollisions will be avoided at address 3 for all users who have only 
°dONLNdË
Ω
î
…(
Δ
îone relative pointing device.°dONLNd
…Z
’(
“ZZWhile the bus is robust with respect to seperating devices which are at the same address, °dONLNda
…
’(
“the°dONLNde
’Z
·
‡(
fiZJADBS driver loading mechanism, which is described blow, made it useful to °dONLNdØ
’
‡
·(
fi
‡try to avoid°dONLNdº
·Z
Ì
W(
ÍZ6having several dissimilar devices at the same address.
°dONLNdÛ
˘Z
r*8Default addresses and handler IDs are assigned by Apple °dONLNd+
˘
r(
rSoftware Licensing when an ADB°dONLNdJZ
r(Z=license contract is completed.  Default address 0 is used by 
°dONLNdá
r(
r!the ADB host; addresses 8 through°dONLNd©Z
e(Z:15 are used as locations to dynamically locate devices at.
°dONLNd‰)Z5
*#Some devices support more than one °dONLNd    )
5)∑4data protocol.  An example is the extended keyboard,°dONLNd    <5ZA≈(>Zwhich can be asked to 
°dONLNd    R5≈A)kHsend separate key codes for the left & right shift keys.  This change is°dONLNd    õAZM‡(JZaccomplished by changing °dONLNd    ¥A‡M)Ü=its handler ID to 3; the new handler ID reflects the new data°dONLNd    ÚMZY
D(VZ0protocol.  If your device receives a request to °dONLNd
"M
DY)Í+change handler IDs (via a listen register 3°dONLNd
NYZe
'(bZ*command), it should only obey the request 
°dONLNd
xY
'e)Õ2if it knows how to speak the protocol specified by°dONLNd
´eZq
>(nZ/the new handler ID.  For example, the extended 
°dONLNd
⁄e
>q)‰,keyboard, when receiving a request to change°dONLNdqZ}€(zZhandler IDs, should accept 
°dONLNd"q€})ÅBthe change if it is going to ID 3 or some other ID it knows about,°dONLNde}Zâ
Ü(ÜZ?and should thereafter report that ID as its own in response to °dONLNd§}
Üâ(Ü
Ütalk register 3 commands; if it
°dONLNdƒâZï(íZYreceives a request to change to handler ID $52, it should ignore it, as it does not know °dONLNdâï(íwhat°dONLNd"ïZ°
G(ûZ/handler ID $52 implies, and continue to report °dONLNdQï
G°)Ì+its original handler ID in response to talk°dONLNd}°Z≠¿(™Zregister 3 commands. ¿X¿

*+9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse(’
3) of 18(ÎZHardwareˇJHRˇˇˇˇˇRH

HR,Times

.+6-Macintosh Technical Notes /4/
˘

°dONLNdH6T
*$.A special case is devices which emulate Apple °dONLNd.H
T
¯)‰*device protocols.  For example, you may be
°dONLNdYT6`“(]6constructing a 17-button mouse °dONLNdxT“`
¯)ú=for use by specially trained squid; it has a special software°dONLNd∂`6l`(i6    protocol 
°dONLNdø``l
¯)*Rto allow it to convey the state of all 17 mouse buttons.  However, you may wish to°dONLNd
l6x
q(u6<emulate the Apple mouse protocol so your device can be used °dONLNd
Nl
qx
¯(u
qas a one button mouse on°dONLNd
gx6ÑÖ(Å6machines which 
°dONLNd
vxÖÑ
¯)OMdon't have your driver software installed.  Due to the software design of the°dONLNd
ƒÑ6êÇ(ç6
ADB manager, °dONLNd
—ÑÇê
¯)LMif your device is at default address 3, it will have the default mouse driver°dONLNdê6ú
Ñ(ô6Kinstalled as its driver at startup regardless of its handler ID; when your 
°dONLNdjê
Ñú
¯(ô
Ñsoftware loads, you can°dONLNdÇú6®
 (•6[install a new driver for your device and tell it to begin talking the 17 button protocol.  
°dONLNd›ú
 ®
¯(•
 You have°dONLNdÊ®6¥†(±6two options: you can °dONLNd˚®†¥
¯)jAhave your device power up with the default Apple mouse handler ID°dONLNd=¥6¿
Ï(Ω6Y($01) or with your own handler ID as assigned by Apple Software Licensing.  If you power 
°dONLNdñ¥
Ï¿
¯(Ω
Ïup°dONLNdô¿6Ã
 (…61with the $01 handler ID, your software will have 
°dONLNd ¿
 Ã
¯)Í-to locate your device by trying to change the°dONLNd¯Ã6ÿ
î(’6Ghandler ID of each device which started out at address 3 to you custom °dONLNd?Ã
îÿ
¯(’
îID, then reading the
°dONLNdTÿ6‰](·6handler °dONLNd\ÿ]‰
¯)'QID of that device back; if the change stuck, then you know you're talking to your
°dONLNdƉ6
ø(Ì6Pdevice, and can install your custom driver.  In addition, the command to change °dONLNd˛‰
ø
¯(Ì
øhandler IDs°dONLNd
6¸
¿(˘6Ttold the device to begin using your custom protocol.  Alternatively, you could have 
°dONLNd^
¿¸
¯(˘
¿your device°dONLNdj¸6
˚(
6&power up with your custom handler ID; °dONLNdê¸˚

¯)≈0this would make identifying your device somewhat°dONLNd¡
6

fl(
6\easier, as your device could be identified by its special handler ID; you would have to use 
°dONLNd

fl

¯(

flsome°dONLNd"
6
 ñ(
6special command to 
°dONLNd5
ñ
 
¯)`Ltell the device that you have installed the new driver and that it can begin°dONLNdÇ
 6
,c(
)6    speaking 
°dONLNdã
 c
,
¯)-Uthe custom protocol.  For example, you could use a talk register 1 to tell the device°dONLNd·
,6
8
´(
56Othat you're ready for the 17 button data protocol.  Both approaches work well, 
°dONLNd0
,
´
8
¯(
5
´but the first one°dONLNdB
86
D
fi(
A6Yis recommended; it ensures that the current protocol can always be determined by looking 
°dONLNdõ
8
fi
D
¯(
A
fiat the°dONLNd¢
D6
P
(
M6.current handler ID; however, it relies on all 
°dONLNd–
D

P
¯)Œ1devices at that default address handling commands°dONLNd
P6
\
{(
Y6Fasking them to change to a different handler ID properly, as a device 
°dONLNdH
P
{
\
¯(
Y
{which incorrectly changes°dONLNdb
\6
h|(
e6its handler ID °dONLNdq
\|
h
¯)FJto your assigned ID would fool you into thinking it was your device.  This°dONLNdº
h6
t
‰(
q6Zdoesn't seem to be a large problem, but there could be some obscure devices with this bug.
°dONLNd    
Ä6
å•*Address Resolution
°dONLNd    *
ò6
§
Ã*QAddress resolution is the process the ADB manager uses to separate devices which °dONLNd    {
ò
Ã
§
¯(
°
à    share the°dONLNd    Ö
§6
∞
C(
≠66same default address, so they power up shadowing each 
°dONLNd    ª
§
C
∞
¯(
≠
C)other at a particular address.  It relies°dONLNd    Â
∞6
º
ê(
π6Eon devices using collision detection to determine when there is more °dONLNd
*
∞
ê
º
¯(
π
êthan one device at a°dONLNd
?
º6
ȍ(
≈6particular address.°dONLNd
S
‘6
‡Î*&An ADB device's register 3 is 2 bytes 
°dONLNd
y
‘Î
‡
¯)µ8long and includes 4 bits in which the address is stored.°dONLNd
≥
‡6
Ï
d(
È6@When the device receives a listen register 3 command, it should 
°dONLNd
Û
‡
d
Ï
¯(
È
d take its address from this 4 bit°dONLNd
Ï6
¯
æ(
ı6Qfield.  When it receives a talk register 3 command, it would be redundant to put °dONLNde
Ï
æ
¯
¯(
ı
æthe device's
°dONLNdr
¯6
3(
67address in that field; the device's address is already °dONLNd©
¯
3
¯)˝(uniquely determined by the fact that the
°dONLNd“6™(
6device is responding to °dONLNdÍ™
¯)tBthe talk register 3 command, which was sent to a specific address.
°dONLNd.6´(6Instead, a random 4-bit °dONLNdF´
¯)uFvalue should be returned in this field; this makes it easier to detect°dONLNdç6(
[(%6?collisions between two devices responding to a talk register 3.°dONLNdÕ46@
*)When a device receives a talk register 3 °dONLNdˆ4
@
¯)Ã/command, it should send back all of register 3,°dONLNd
&@6Lù(I6including the random 
°dONLNd
;@ùL
¯)gKfield, and it should pay careful attention to collision detection. Should a°dONLNd
áL6X
Ã(U6Qdevice detect a collision when responding to a talk register 3 request, there is °dONLNd
ÿL
ÃX
¯(U
à    a special°dONLNd
‚X6d
(a6.provision in the ADB protocol which says that 
°dONLNdX
d
¯)fi1the device should ignore the next listen register°dONLNdBd6pA(m63 °dONLNdDdAp
¯)Vwhich asks it to change address. The next time the device receives a listen register 3
°dONLNdõp6|l(y6    command, °dONLNd§pl|
¯)6Qit should check to see if the handler ID field is set to $FE.  This is a reserved
°dONLNdˆ|6à
$(Ö63handler ID used to distinguish this type of listen °dONLNd)|
$à
¯)Ó,request; if the handler ID field is $FE, the
°dONLNdVà6î
ÿ(ë6Wdevice should only change address if it has safely transmitted a complete packet since °dONLNd≠à
ÿî
¯(ë
ÿits last°dONLNd∂î6†
å(ù6Icollision.  Of course, the device should not adopt the handler ID of $FE. ¿4¿
˘

*8
4) of 18)∫9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse+flHardwareˇ∂HRˇˇˇˇˇRH

HR,Times

.+Z-Developer Technical Support(-
ÁJanuary 1994 /X/
°dONLNd<ZHÌ(EZHere is a summary of a typical 
°dONLNd<ÌH)ì>sequence where the host is attempting to separate two devices.°dONLNd_HZT
ˆ(QZWThere are two devices of the same type, which I will call Fred and Wilma, at address 3.°dONLNd∑`~l
û+$=1) The host will send a talk register 3 command to address 3.°dONLNdıl~x
÷*E2) Both Fred and Wilma will receive the command and begin to respond.
°dONLNd
;x~Ñ
 * 3) Even though they are sending °dONLNd
[x
 Ñ)¢1the same data, and they begin sending at the same
°dONLNd
çÑ~ê
¯(ç~Otime, they select different random numbers to insert into the "device address" °dONLNd
‹Ñ
¯ê(ç
¯field of°dONLNd
Âê~úfl(ô~register 3, bits 7-10.°dONLNd
¸ú~®*V4) Wilma detects a collision while trying to send bit 7 and immediately stops sending.°dONLNdS®~¥
Û*Q5) Fred does not detect a collision and completes his transmission of register 3.
°dONLNd•¥~¿‡*6) The host, seeing °dONLNdπ¥‡¿)bBthat a device has responded to its talk register 3, sends a listen°dONLNd¸¿~Ã
g(…~4register 3 to address 3, asking the device there to 
°dONLNd0¿
gÃ)È#move to address $F.  The handler ID°dONLNdTÃ~ÿ
ˇ(’~Vfield is $FE, indicating that a device should not move if it has detected a collision.°dONLNd´ÿ~‰
O*+7) Both Fred and Wilma receive the request.°dONLNd◊‰~
ö*98) Fred moves to address $F; however, Wilma does not, as 
°dONLNd‰
ö(Ì
öshe has been locked out of°dONLNd+~¸(˘~Smoving because she detected a collision while responding to her last talk register °dONLNd~¸(˘
3°dONLNdĸ~
∞(
~command.°dONLNdâ
~
ã*9) 
°dONLNdå
ã
)
SThe host sends a talk register 3 to address $F to ensure that a device moved there.°dONLNd·
~
 
a(
~.Fred responds, assuring the host he has moved.
°dONLNd
 ~
,
–*G10) The host repeats the separation procedure, sending a talk register °dONLNdW
 
–
,(
)
–3 to address 3,°dONLNdg
,~
8fi(
5~followed by a listen 
°dONLNd|
,fi
8)`Bregister 3 to address 3 asking the device there to move to address°dONLNdø
8~
Dè(
A~$E.°dONLNd√
D~
P
f*211) This time, Wilma does not detect a collision, 
°dONLNdı
D
f
P)Ë&as she is the only device remaining at°dONLNd
P~
\
9(
Y~&address 3, so she moves to address $E.°dONLNdC
\~
h
*J12) The host sends yet another talk register 3 to address 3, but does not °dONLNdç
\

h(
e
    receive a°dONLNdó
h~
t
•(
q~>response, as there are no more devices remaining at address 3.°dONLNd÷
t~
Ä
…*D13) The host relocates Wilma from address $E back to address 3 with 
°dONLNd
t
…
Ä(
}
…a listen register 3°dONLNd.
Ä~
å
    (
â~command sent to address $E.°dONLNdK
å~
ò
†*<14) The host moves on and repeats the process for address 4.°dONLNdà
§Z
∞
l(
≠Z9Each and every ADB controller isn't guaranteed to follow 
°dONLNd¡
§
l
∞(
≠
l&this procedure precisely, but it gives°dONLNdË
∞Z
ºü(
πZa feeling for °dONLNdˆ
∞ü
º)EFthe principle behind the address resolution process.  You may see some°dONLNd=
ºZ
»
⁄(
≈ZOimplementations moving devices many more times than is necessary; this is done 
°dONLNdå
º
⁄
»(
≈
⁄because some°dONLNdô
»Z
‘
ÿ(
—ZPdevices have been manufactured to tolerances close enough that not only do they 
°dONLNdÈ
»
ÿ
‘(
—
ÿsend their bits°dONLNd˘
‘Z
‡(
›Z^at exactly the same time and so cannot detect collisions with each other, but they select the 
°dONLNd    W
‘
‡(
›same°dONLNd    \
‡Z
Ï
∂(
ÈZ@random numbers to transmit.  We recommend that you include some °dONLNd    ú
‡
∂
Ï(
È
∂low tolerance device°dONLNd    ±
ÏZ
¯Ñ(
ıZ    (such as 
°dONLNd    ∫
ÏÑ
¯)*Wa capacitor on your reset line) to ensure that various devices will respond differently°dONLNd

¯Z
P(
Z7and be able to detect their collisions with each other.
°dONLNd
JZù*Autopolling°dONLNd
V(Z4
Í*TAutopolling is the primary method via which the host fetches data from your device. 
°dONLNd
™(
Í4(1
Í
 The basic°dONLNd
µ4Z@í(=Z
mechanism 
°dONLNd
ø4í@)8Sis that the host repeatedly issues talk register 0 commands to your device; if your°dONLNd@ZL‰(IZdevice responds with data, it 
°dONLNd1@‰L)ä@is passed to your device's driver, which should act on it as new°dONLNdrLZXq(UZdata.°dONLNdxdZp
    *$This implies that register 0 should °dONLNdúd
    p)Ø7be the primary data transfer register for most devices;°dONLNd‘pZ|é(yZregisters 1 
°dONLNd‡pé|)4Qand 2 are usually only used for supplementary data to configure the device.  Most°dONLNd2|Zà‡(ÖZdevice drivers have no need 
°dONLNdN|‡à)ÜAto issue commands to their device, as all necessary data has been°dONLNdêàZî·(ëZtransferred within register 0. ¿X¿

*D9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse(’
5) of 18(ÎZHardwareˇÿHRˇˇˇˇˇRH

HR,Times

.+6-Macintosh Technical Notes /4/
˘
°dONLNd<6H◊*!When a device wishes to transmit 
°dONLNd!<◊H
¯)°<data, it should wait until a command is issued to it or some°dONLNd^H6T
ã(Q6Iother device.  If, when this transmission is completing, it still wishes °dONLNdßH
ãT
¯(Q
ãto transfer data (if the°dONLNd¿T6`
(]6.command was sent to our device, it might have 
°dONLNdÓT
`
¯)·/fetched the data already,) it should assert SRQ°dONLNd
`6l
:(i65after the data portion of the command by holding the °dONLNd
S`
:l
¯(i
:&bus low for 300 µs after the stop bit.
°dONLNd
{l6xŸ(u6#This will alert the host that some °dONLNd
ûlŸx
¯)£;device wishes to transmit data.  It will then begin polling°dONLNd
⁄x6Ñ
å(Å6Hthose addresses which it knows hold devices.  If a device does not have 
°dONLNd"x
åÑ
¯(Å
åany data, the host will°dONLNd:Ñ6êT(ç6move °dONLNd?ÑTê
¯)Ton to the next address, asking each device in turn, until SRQ is no longer asserted,°dONLNdîê6ú
(ô62indicating that all pending data has been fetched.
°dONLNd«®6¥å*When an SRQ is °dONLNd÷®å¥
¯)VMnot asserted, the host will continually poll the last device to send it data,°dONLNd$¥6¿
Δ(Ω6Usending it talk register 0 commands periodically.  This is done under the assumption 
°dONLNdy¥
Δ¿
¯(Ω
Δthat this is°dONLNdÜ¿6Ãm(…6
likely to be 
°dONLNdì¿mÃ
¯)7Wthe next place the user interacts; if the user types a character, she is very likely to°dONLNdÎÃ6ÿ
±(’6Ptype another soon.  On current hosts, this can happen up to 150 times a second, 
°dONLNd;Ã
±ÿ
¯(’
±although it can°dONLNdKÿ6‰
s(·6Bhappen much less frequently in some cases. If the device responds 
°dONLNdçÿ
s‰
¯(·
swith any data, the host will°dONLNd™‰6„(Ì6'call the device's driver with the data.°dONLNd“¸6
Ó*%Your device should only respond with 
°dONLNd˜¸Ó

¯)∏6data when sent a talk register 0 command if it has new°dONLNd.
6

3(
68data. If the status of the device has not changed since 
°dONLNdf

3

¯)˝,the last talk register 0, then it should not°dONLNdì
6
 
g(
6Arespond at all, allowing the bus to time out. This is useful for °dONLNd‘

g
 
¯(

gtwo reasons: first, it tends to°dONLNdÙ
 6
,
g(
)6;reduce the demands on the host, as your driver need not be °dONLNd/
 
g
,
¯(
)
gcalled when your device has°dONLNdK
,6
8†(
56nothing useful to say. 
°dONLNdb
,†
8
¯)jBSecond, in some ADB implementations, the host can get "hung up" on°dONLNd•
86
D
€(
A6Xyour device if you always respond. For example, say that you have a device at address 4 
°dONLNd˝
8
€
D
¯(
A
€which°dONLNd
D6
Pœ(
M6 will always respond, regardless 
°dONLNd#
Dœ
P
¯)ô>of whether it has new data, there is another device at address°dONLNdb
P6
\
À(
Y6Y7, and the system is currently autopolling address 2. If the device at address 7 asserts 
°dONLNdª
P
À
\
¯(
Y
ÀSRQ, the°dONLNdƒ
\6
h
∫(
e6Qsystem will begin looking through the addresses looking for the device which has 
°dONLNd
\
∫
h
¯(
e
∫
data to send.°dONLNd$
h6
t
W(
q6;When it reaches your device at address 4, your device will °dONLNd_
h
W
t
¯(
q
W respond, although it has nothing
°dONLNdÄ
t6
Ä
ø(
}6Pnew to say. On some implementations, this will cause the host to repeatedly ask °dONLNd–
t
ø
Ä
¯(
}
øyour device
°dONLNd‹
Ä6
åÆ(
â6for more data, and your °dONLNdÙ
ÄÆ
å
¯)xAdevice will continue responding. Meanwhile, device 7 is withering
°dONLNd    6
å6
òª(
ï6away at the end of the bus °dONLNd    Q
åª
ò
¯)Ö>and will never get serviced. What your device should do is not°dONLNd    ê
ò6
§Ï(
°6*respond to the talk register 0, as it has 
°dONLNd    ∫
òÏ
§
¯)∂8no new data; this will allow all host implementations to°dONLNd    Û
§6
∞
™(
≠6Opass you by and reach the device at address 7 which needs the host's attention.°dONLNd
C
º6
»
*.A useful summary of a reasonable algorithm is:°dONLNd
r
»Z
‘^+$
•°dONLNd
t
»c
‘Ï)    Wait for a command to begin°dONLNd
ê
‘Z
‡^(
›Z
•°dONLNd
í
‘c
‡
Ú)    OIf the command is directed to my address, handle it.  If it is a talk register °dONLNd
·
‘
Ú
‡
¯(
›
Ú
0°dONLNd
„
‡c
Ï
å(
Èc>command, only respond if there is new data waiting to be sent.°dONLNd"
ÏZ
¯^(
ıZ
•°dONLNd$
Ïc
¯
`)    7At the end of the command, if there is data waiting to 
°dONLNd[
Ï
`
¯
¯)˝be sent, assert SRQ, regardless°dONLNd{
¯c
Y(
c1of who the original command was directed towards.
°dONLNd≠6
*(
62This simple behavior will produce the appropriate °dONLNdfl
*
¯)Ù'responses and SRQ generation for proper°dONLNd6
°(6Obus functioning.  It shouldn't be necessary for your device to explicitly have 
°dONLNdV
°
¯(
°any knowledge of°dONLNdg6(
°(%6Qwhether it is the "active" device or not; a robust basic behavior will eliminate 
°dONLNd∏
°(
¯(%
°any need for such°dONLNd (64q(16information.°dONLNd◊@6L
f*@As an optimization, all recent versions of the ADB manager will 
°dONLNd
@
fL
¯(I
fnot automatically poll a device°dONLNd
7L6X¨(U6which does not have a °dONLNd
ML¨X
¯)vDdriver service routine installed.  In this case, they will switch to
°dONLNd
íX6d
Q(a6;autopolling some other device, even if that device has not °dONLNd
ÕX
Qd
¯(a
Q been recently communicated with.°dONLNd
Ôd6p
/(m65However, the host may poll a device, even if it does 
°dONLNd$d
/p
¯)˘+not have a service request, in order to try°dONLNdPp6|∏(y6to clear an SRQ on the bus. ¿4¿
˘

*\
6) of 18)∫9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse+flHardwareˇ‡HRˇˇˇˇˇRH

HR,Times

.+Z-Developer Technical Support(-
ÁJanuary 1994 /X/

°dONLNd<ZHº(EZBus Initialization°dONLNdTZ`“*Bus initialization doesn't 
°dONLNd.T“`)xAwork exactly as it might seem from looking at some documentation.°dONLNdq`Zl
_(iZ0A SendReset command is never sent to individual °dONLNd°`
_l(i
_$devices; rather, when a bus reset is
°dONLNdΔlZx
◊(uZHrequested, the ADB manager sends a SendReset command which is broadcast °dONLNd
l
◊x(u
◊to all devices,°dONLNd
xZÑ
u(ÅZ9causing them to reset themselves and go to their default °dONLNd
Wx
uÑ(Å
uaddresses and handler IDs.  The°dONLNd
wÑZê(çZXrelocation and driver loading procedure will follow immediately after the reset command °dONLNd
œÑê(çis°dONLNd
“êZúq(ôZsent.

°dONLNd
ÿ®Z∑≤*ADB Drivers
°dONLNd
‰√Zœ¬*Driver Installation
°dONLNd
¯€ZÁ
°*AIn the past, the recommended way to install an ADB driver was to °dONLNd9€
°Á(‰
°install a resource of type,
Courier°dONLNdTÁZÛÑ(ÒZ'ADBS'°dONLNdZËÑÙü)* with 
°dONLNd`ËüÙ)Nthe same resource ID as your device's default address in the system file which°dONLNdØÙZ

˚(˝Z\held code to install the driver for the ADB driver, along with the driver itself.  When the 
°dONLNdÙ
˚
(˝
˚system°dONLNd

Z

Œ(

Zwas booted or when the 
°dONLNd)

Œ


µ)t0bus was reinitialized, the system would get the °dONLNdY

µ

fl)Á'ADBS'°dONLNd_


fl

)*resource and°dONLNdl

Z

&(
Z*execute it, which would let your code set °dONLNdñ


&
)Ã3the driver for that device up.  Unfortunately, this°dONLNd 
Z
%(
"Z system is not well designed for 
°dONLNdÍ

%)ñ>the wide variety of devices available; the most prominent flaw°dONLNd)
&Z
2ä(
/Zis that the °dONLNd5
%ä
1¥)0'ADBS'°dONLNd;
&¥
2
,)*resources are indexed by 
°dONLNdT
&
,
2)x2default address only; thus, there is no way to use°dONLNdá
3Z
?k(
<Zthe °dONLNdã
2k
>ï)'ADBS'°dONLNdë
3ï
?Õ)*
mechanism 
°dONLNdõ
3Õ
?)8Gto load drivers for two different devices at address 7, as there can be°dONLNd„
?Z
KÛ(
HZ only one resource with ID 7.  A 
°dONLNd
?Û
K)ôCfurther flaw is that it requires installation into the system file,°dONLNdG
KZ
W{(
TZwhich °dONLNdM
K{
W)!Qis not currently recommended for a number of reasons.  In any case, it has always°dONLNdü
WZ
c
·(
`ZMrequired a special installation and deinstallation program and has been more °dONLNdÏ
W
·
c(
`
·
than a little°dONLNd˙
cZ
o∫(
lZconfusing for users.°dONLNd
{Z
á

*"Currently, the recommended method 
°dONLNd1
{


á)∞8is to supply the user with a system extension which will°dONLNdj
áZ
ìä(
êZ
load your 
°dONLNdt
áä
ì)0Vdriver; this can either be a simple extension, or it can be contained within a control°dONLNdÀ
ìZ
üπ(
úZpanel, should your °dONLNdfi
ìπ
ü)_Fdevice require some user interface for configuration.  Your code, when°dONLNd%
üZ
´
9(
®Z0loaded, should look for your device and install 
°dONLNdU
ü
9
´)fl2your driver for it. If your device is at a default°dONLNdà
´Z
∑
ã(
¥Z=address which is not shared with standard Apple devices, you °dONLNd≈
´
ã
∑(
¥
ãdon't have to concerned with°dONLNd‚
∑Z
√
¯(
¿Z[what driver is installed for you by default; your device can just power up at its standard 
°dONLNd=
∑
¯
√(
¿
¯address°dONLNdE
√Z
œ
(
ÃZ)with its handler ID.  Your extension can 
°dONLNdn
√

œ)¿5then locate your device's current address by indexing°dONLNd§
–Z
‹
m(
ŸZ8through all the known devices with the ADB manager call 
°dONLNd‹
œ
m
€
»(
Ÿ
m
GetADBInfo();°dONLNdÈ
–
»
‹)[ when you find a°dONLNd˙
‹Z
Ë(
ÂZIdevice whose initial address and handler ID match your device's, you can °dONLNd    C
‹
Ë(
Âcall
°dONLNd    H
ËZ
ÙÆ(
ÚZSetADBInfo()°dONLNd    T
ÈÆ
ı≤)T
 °dONLNd    U
È≤
ı)Jto install your driver's completion routine to handle autopolled data from°dONLNd    †
ıZ
ï(
˛Zyour device.°dONLNd    ≠
Z
‹*KBecause your ADB driver is in a system extension which will not load until °dONLNd    ¯

‹(
‹
well into the
°dONLNd
Z%
Δ("ZLsystem startup process, if your device is a standard one (a pointing device °dONLNd
R
Δ%("
Δor keyboard) you°dONLNd
c%Z1
(.Z&might need to provide standard system 
°dONLNd
â%
1)π8functionality before your driver loads in order to allow°dONLNd
¬1Z=
≤(:ZLthe user to interact with the system during the startup process.  This also 
°dONLNd1
≤=(:
≤allows the user to use°dONLNd%=ZI·(FZyour device to control their °dONLNdB=·I)á?machine even if they don't have the software installed, such as°dONLNdÇIZU
≈(RZOwhen they are booting off of a floppy.  In this case, your device will need to 
°dONLNd—I
≈U(R
≈be able to emulate°dONLNd‰UZa
8(^Z)the Apple protocol for mouse or keyboard °dONLNd
U
8a)fi,devices until your software driver loads, as°dONLNd:aZm
(jZ&discussed above in "Default Addresses 
°dONLNd`a
m)∫7and Handler IDs".  Until your driver is installed, your°dONLNdòmZy
Ã(vZSdevice will be serviced by the default driver for this address; this means that if 
°dONLNdÎm
Ãy(v
Ãyour device is at°dONLNd˝yZÖö(ÇZ
address 2 or °dONLNd
yöÖ)@M3, even if it cannot emulate an Apple device, it must supply harmless data in°dONLNd
XÖZë
π(éZMregister 0 until your driver loads and is installed, as the Apple ADB driver 
°dONLNd
•Ö
πë(é
πfor that address may°dONLNd
∫ëZùœ(öZinadvertantly receive the 
°dONLNd
‘ëœù)uHcontents of your register 0 and attempt to use it as input data.  If the°dONLNdùZ©±(¶Zdata in your field °dONLNd0ù±©)WHcaused effects such as the mouse button or shift key sticking down, this°dONLNdy©Zµ˝(≤Z"could cause problems for the user. ¿X¿

*#9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse(’
7) of 18(ÎZHardwareˇ"≤HRˇˇˇˇˇRH

HR,Times

.+6-Macintosh Technical Notes /4/
˘

°dONLNdH6TX*$If you °dONLNdHXT
¯)"Puse the recommended procedure for handler IDs in this case, powering up with the
°dONLNdXT6`
à(]6Bappropriate Apple handler ID and switching to your custom ID when °dONLNdöT
à`
¯(]
àyour driver loads, you°dONLNd±`6l
;(i65will need to use ADB commands to find your device at 
°dONLNdÊ`
;l
¯(i
;&startup.  You should index through the°dONLNd

m6y¡(v6connected ADB devices with ,
Courier°dONLNd
(l¡x
)ãGetADBInfo()°dONLNd
4m
y
)T
 
°dONLNd
5m
y
¯).and if you find a device which has an original°dONLNd
dy6Ö
’(Ç6Zaddress and handler ID which indicates that it might be your device, attempt to switch it 
°dONLNd
æy
’Ö
¯(Ç
’to your°dONLNd
ΔÜ6íó(è6handler ID by using °dONLNd
⁄Öóë»)aADBOp()°dONLNd
·Ü»í
|)1* to send it a listen register 3 to change 
°dONLNdÜ
|í
¯)¥its handler ID.  (You will°dONLNd&í6û
ã(õ6Hfirst need to read its register 3 with a talk register 3 command so you °dONLNdní
ãû
¯(õ
ãcan correctly copy the°dONLNdÖû6™
y(ß6Gvarious flag bits in the register you send to the device.)  You should 
°dONLNdÃû
y™
¯(ß
ythen issue a talk register 3°dONLNdÈ™6∂
Á(≥6Ycommand to the device and examine the response to see if the new handler ID was accepted 
°dONLNdB™
Á∂
¯(≥
Áand°dONLNdF∂6¬
Ë(ø6_reported back by the device; if so, you can be certain that this device is your device and you 
°dONLNd•∂
ˬ
¯(ø
Ëcan°dONLNd©√6œ`(Ã6
then call °dONLNd≥¬`Œ¥)*SetADBInfo()°dONLNdø√¥œ
•)T7 to install your driver as the handler for that device.
°dONLNd˜‹6Ë√(Â6In the original method using °dONLNd€√ÁÌ)ç'ADBS'°dONLNd‹ÌË
8)* resources, the °dONLNd*‹
8Ë
¯)K&system could automatically reload your°dONLNdQË6Ù˚(Ò6,driver any time the bus was reinitialized.  
°dONLNd}Ë˚Ù
¯)≈5If your driver is loaded via a system extension there°dONLNd≥Ù6

/(˝65isn't any way for the system to find your device and 
°dONLNdËÙ
/

¯)˘*driver and reconnect them after the bus is°dONLNd
6
∫(
    6reinitialized and devices are 
°dONLNd1
∫

¯)ÑArelocated.  Thus, you've got to manually reconnect your driver to°dONLNds
6

(
60your device each time the bus is reinitialized. 
°dONLNd£



¯)÷1 Fortunately, there is a system provision for you°dONLNd’
6
%
?(
"6>to be notified each time the bus is reinitialized; there is a 
°dONLNd

?
%
¿(
"
?low memory global called °dONLNd,

¿
$
¯)ÅjADBProc°dONLNd5
%6
1
–(
.6V(at address $6B8) which is a pointer to a procedure to be called just before and just °dONLNdã
%
–
1
¯(
.
–    after the°dONLNdï
26
>
¬(
;6Zbus is initialized.  When the procedure is called before the bus is initialized, register °dONLNdÔ
1
¬
=
–(
;
¬D0°dONLNdÒ
2
–
>
fi) is 
°dONLNdı
2
fi
>
¯)set to°dONLNd¸
>6
Jö(
G60; after, it is set to °dONLNd
>ö
J
¯)dB1.  When your extension loads and installs your driver, you should°dONLNdV
K6
W°(
T6remember the value in 
°dONLNdl
K°
W≥)kthe °dONLNdp
J≥
VÎ)jADBProc°dONLNdx
KÎ
W
¯)89 global and then install a pointer to a procedure of your°dONLNd≤
W6
c∂(
`6own in that location; when 
°dONLNdÕ
W∂
c
¯)ÄFthis procedure is called, it should do its thing, then call through to°dONLNd
d6
p
B(
m66the next procedure in the chain, whose address was in °dONLNdJ
c
B
o
z(
m
BjADBProc°dONLNdR
d
z
p
∂)8 before you °dONLNd^
d
∂
p
¯)<replaced it (if°dONLNdn
p6
|n(
z6jADBProc°dONLNdv
qn
}
ö)8< was equal to 0 before you installed, just return from your °dONLNd≤
q
ö
}
¯(
z
öprocedure).  Don't°dONLNd≈
~6
ä≤(
á6forget to preserve register °dONLNd·
}≤
â¿)|D0°dONLNd„
~¿
ä—) so 
°dONLNdÁ
~—
ä
¯)>subsequent procedures can tell if they are being called before°dONLNd    &
ä6
ñÕ(
ì6$or after the reinitialization.  The 
°dONLNd    J
äÕ
ñ
¯)óAactions you take in the post-initialization case should basically°dONLNd    å
ñ6
¢
≠(
ü6Nduplicate your original installation procedure, including looking through all °dONLNd    ⁄
ñ
≠
¢
¯(
ü
≠the devices for°dONLNd    Í
£6
؜(
¨6!devices of your type and calling °dONLNd

¢œ
Æ
#)ôSetADBInfo()°dONLNd

£
#
Ø
⁄)T) to install your driver for your devices.°dONLNd
A
ª6
«
W(
ƒ69For history buffs, this is the second time we've changed °dONLNd
z
ª
W
«
¯(
ƒ
Wour recommended procedure for°dONLNd
ò
«6
”w(
–6loading ADB 
°dONLNd
§
«w
”
¯)ANdrivers.  Initially, it was recommended that ADB drivers be loaded with INITs;°dONLNd
Û
‘6
‡°(
›6however, at the time, °dONLNd    
”°
flŸ)kjADBProc°dONLNd
‘Ÿ
‡›)8
 °dONLNd
‘›
‡
¯)7did not exist, so when the Macintosh Portable came out,°dONLNdJ
‡6
Ï
B(
È69INIT-handled devices had the fatal flaw of not reloading 
°dONLNdÉ
‡
B
Ï
¯(
È
B$their drivers when the Macintosh was°dONLNd®
Ï6
¯
z(
ı6Eput to sleep and reawakened, since this procedure involved resetting 
°dONLNdÌ
Ï
z
¯
¯(
ı
zthe bus.  This cause us to°dONLNd
˘6“(6begin recommending the use of °dONLNd&
˘“Â)úthe °dONLNd*
¯Â
)'ADBS'°dONLNd0
˘

¯)*/resource, since in this way the driver could be°dONLNd`6˛(6)reloaded from the System file.  However, 
°dONLNdâ˛
)»the °dONLNdç

:)'ADBS'°dONLNdì
:
¯)*%approach has so many major flaws that°dONLNdπ6
(6-we have stopped recommending it now that the °dONLNdÊ

O)·jADBProc°dONLNdÓ
O
⁄)8 global has been introduced.  
°dONLNd

⁄
¯)ãAs far°dONLNd
 6,r()6as I can tell, °dONLNd
"r+™)<jADBProc°dONLNd
* ™,
á)80 has been available at least since System 6.0.4.
°dONLNd
[86D
Ç(A6GFor true history buffs, or possibly for specialized applications, here °dONLNd
¢8
ÇD
¯(A
Çis the description of the°dONLNd
ºD6P`(N6'ADBS'°dONLNd
¬E`Q„)*resource functionality: the °dONLNd
fiD„P

)É'ADBS'°dONLNd
‰E

Q
ï)*resource is loaded into the °dONLNdE
ïQ
¯)àsystem heap by the
°dONLNdR6^∂([6system and detached with °dONLNd,Q∂]
&)ÄDetachResource()°dONLNd<R
&^
«)p".  The resource is then called by °dONLNd^Q
«]
‹)°JSR°dONLNdaR
‹^
Ô)ing °dONLNdeR
Ô^
¯)to
°dONLNdh_6k
(h6.the first byte of the resource. At this time, °dONLNdñ_
k
∏)—%the registers are set up as follows: °dONLNdª^
∏j
Δ)±A0°dONLNdΩ_
Δk
¯)
 holds the°dONLNd»l6x](u6address 
°dONLNd–l]x})'of the °dONLNd◊k}wß) 'ADBS'°dONLNd›lßx
¯)*Gresource data (although it is no longer in a resource handle, thanks to°dONLNd%y6ÖH(Ç6the °dONLNd)xHÑ∏)DetachResource()°dONLNd9y∏Ö
e)p' call); if a handle to the resource is °dONLNd`y
eÖ
è)≠needed, °dONLNdhx
èÑ
¯)*RecoverHandle()°dONLNdxÜ6í
+(è68can be called to retrieve it.  The low byte of register °dONLNd∞Ö
+ë
9)ıD0°dONLNd≤Ü
9í
Ø) holds the ADB device's 
°dONLNd Ü
Øí
¯)vcurrent address°dONLNd⁄í6û
º(õ6O(due to relocation, this might not be the same as the default address) and the °dONLNd)í
ºû
¯(õ
ºlow byte of°dONLNd5ü6´\(®6    register °dONLNd>û\™j)&D1°dONLNd@üj´
G)0 holds the handler ID of the device in question. ¿4¿
˘

(’6
8) of 18)∫9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse+flHardwareˇZHRˇˇˇˇˇRH

HR,Times

.+Z-Developer Technical Support(-
ÁJanuary 1994 /X/

°dONLNdHZW
(TZThe Cursor Device Manager
°dONLNdcZo
Á*SIn order to be able to manage an expanding set of relative movement devices, Apple 
°dONLNdmc
Áo(l
Áhas created°dONLNdyoZ{
∏(xZBthe Cursor Device Manager, which is a software architecture which °dONLNdªo
∏{(x
∏provides a standard°dONLNdœ{Zá
›(ÑZPinterface to devices of widely varying resolutions and capabilities.  This also °dONLNd
{
›á(Ñ
›
allows better°dONLNd
-áZìò(êZmanagement 
°dONLNd
8áòì)>Tof multiple relative devices on a single bus; in the old architecture, all connected°dONLNd
çìZü
P(úZ6devices shared a single button state and acceleration 
°dONLNd
Ó
Pü)ˆ'curve, which became a problem for Apple°dONLNd
ÎüZ´(®ZWand for third-party device manufacturers.  The Cursor Device Manager provides a number °dONLNdBü´(®of°dONLNdE´Z∑É(¥Z
calls for 
°dONLNdO´É∑))Vfinding, configuring, and manipulating relative devices connected to the bus.  It also°dONLNd¶∑Z√ó(¿Z
supports the 
°dONLNd≥∑ó√)=Lnew extended mouse protocol, which is described below in the "Apple Devices"°dONLNd√Zœ(ÃZsection.
°dONLNd    €ZÁ

*Cursor Device Manager types°dONLNd%ÛZˇ
ì*BThe Cursor Device Manager treats each relative or absolute device 
°dONLNdgÛ
ìˇ(¸
ìas a "Cursor Device".  Each°dONLNdÉ
Z
Ω(
    Zone is specified by a ,
Courier°dONLNdôˇΩ

)c
CrsrDevRec°dONLNd£



ã)F which is defined as follows:
    °dONLNd¡
Z
#◊(
 ZCrsrDevPtr = ^CrsrDevRec;°dONLNd€
"Z
-π*
CrsrDevRec = RECORD°dONLNd
,l
7£+
nextCrsrDev°dONLNd¸
,Ω
7˘)Q:CrsrDevRec^°dONLNd    
,
D
7
Û)á#; ptr to next record in linked list°dONLNd.
6l
A£(
>lwhichCursor°dONLNd:
6Ω
A˛)Q
:CrsrDataRec^°dONLNdH
6
D
A
fl)á; ptr to data for target cursor°dONLNdi
@l
Kä(
HlrefCon°dONLNdp
@Ω
KÂ)Q:LongInt°dONLNdy
@
D
K
≠)á; Application defined°dONLNdê
Jl
Uä(
Rlunused°dONLNdó
JΩ
UÂ)Q:LongInt°dONLNd†
J
D
U
≠)á; reserved for future°dONLNd∑
^l
iÖ(
fldevID°dONLNdΩ
^Ω
i‡)Q:OSType°dONLNd≈
^
D
i
Û)á#; device identifier(from ADB reg 1)°dONLNdÍ
hl
sû(
pl
resolution°dONLNdı
hΩ
s€)Q:Fixed°dONLNd¸
h
D
s
Û)á#; units/inch (orig. from ADB reg 1)°dONLNd!
rl
}î(
zldevClass°dONLNd*
rΩ
}÷)Q:Char°dONLNd0
r
D
}
Û)á#; device class     (from ADB reg 1)°dONLNdU
|l
áû(
Ñl
cntButtons°dONLNd`
|Ω
á÷)Q:Char°dONLNdf
|
D
á
Û)á#; # of buttons     (from ADB reg 1)°dONLNdã
Ül
ëä(
élspare1°dONLNdí
ÜΩ
ë÷)Q:Char°dONLNdò
Ü
D
ë
v)á
; reserved°dONLNd§
öl
•è(
¢lbuttons°dONLNd¨
öΩ
•÷)Q:Char°dONLNd≤
ö
D
•
≤)á; state of all buttons°dONLNd 
§l
Øî(
¨lbuttonOp°dONLNd”
§Ω
Ø
!)Q:Array[0..8] of Char°dONLNdË
§
D
Ø
’)á; action performed per button°dONLNd
Æl
π£(
∂lbuttonTicks°dONLNd
ÆΩ
π
0)Q:Array[0..8] of LongInt°dONLNd+
Æ
D
π
‰)á ; ticks when button last went up°dONLNdM
∏l
√û(
¿l
buttonData°dONLNdX
∏Ω
√
0)Q:Array[0..8] of LongInt°dONLNdp
∏
D
√
fl)á; data for the button operation°dONLNdë
¬l
Õ∑(
 ldoubleClickTime°dONLNd°
¬Ω
ÕÂ)Q:LongInt°dONLNd™
¬
D
Õ
–)á; device’s double click time°dONLNd»
Ãl
ר(
‘lacceleration°dONLNd’
ÃΩ
◊€)Q:Fixed°dONLNd‹
Ã
D
◊
≤)á; current acceleration°dONLNdÙ
‡l
Σ(
ËlaccelPoints°dONLNd
‡Ω
Η)Q:Ptr°dONLNd
‡
D
Î)á'; Private: Ptr to array of  (dev_delta,°dONLNd0
Í
D
ı
∑*
;     slope, intercept)°dONLNdI
Ùl
ˇä(
¸ldeltaX°dONLNdP
ÙΩ
ˇ€)Q:Fixed°dONLNdW
Ù
D
ˇ
’)á; Private: accumulated deltas°dONLNdv
˛l    ä(ldeltaY°dONLNd}
˛Ω    €)Q:Fixed°dONLNdÑ
˛
D    
{)á; Private: °dONLNdë
˛
¬    
«)~
"°dONLNdîlä(lerrorX°dONLNdõΩ€)Q:Fixed°dONLNd¢
D
’)á; Private: accumulated errors°dONLNd¡lä(lerrorY°dONLNd»Ω€)Q:Fixed°dONLNdœ
D
{)á; Private: °dONLNd‹
¬
«)~
"°dONLNdfll'Ö($ldenom°dONLNdÂΩ'€)Q:Fixed°dONLNdÏ
D'
¯)á$; Private: fraction of the errors to°dONLNd&
D1
£*
;     use next time°dONLNd)0l;ä(8lspread°dONLNd00Ω;€)Q:Fixed°dONLNd70
D;)á&; Private: Number of samples to spread°dONLNda:
DE
ô*
;     errors over°dONLNdtDlOè(LlnewData°dONLNd|DΩO÷)Q:Char°dONLNdÇD
DO
Ó)á"; Private: set when deltas are new°dONLNd¶NlYä(Vlspare2°dONLNd≠NΩY÷)Q:Char°dONLNd≥N
DY
v)á
; reserved°dONLNdæXZcn(`ZEND;
°dONLNd√oZ{
Ç*@The cursor controlled by this cursor device is described with a °dONLNd    n
Çz
œ(x
ÇCrsrDataRec°dONLNd    o
œ{
“)M
:
    °dONLNd    áZí·(èZCrsrDataPtr = ^CrsrDataRec;°dONLNd    ,ëZúë*
CrsrDataRec°dONLNd    8ëΩúÂ)c= RECORD°dONLNd    Bõl¶®(£lnextCrsrData°dONLNd    OõΩ¶˛)Q
:CrsrDataRec^°dONLNd    ]õ
D¶
≠)á; next in global list°dONLNd    u•l∞£(≠ldisplayInfo°dONLNd    Å•Ω∞—)Q:Ptr°dONLNd    Ü•
D∞
¡)á; reserved for future use ¿X¿

(’Z9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse(’
9) of 18(ÎZHardwareˇ∫HRˇˇˇˇˇRH

HR,Times

.+6-Macintosh Technical Notes /4/
˘,
Courier
    °dONLNd<HGf+whereX°dONLNd<ôG∑)Q:Fixed°dONLNd<
 G
â)á; horizontal position°dONLNd%FHQf(NHwhereY°dONLNd,FôQ∑)Q:Fixed°dONLNd3F
 Q
)á; vertical position°dONLNdHPH[a(XHwhere°dONLNdNPô[∑)Q:Point°dONLNdUP
 [
Ñ)á; the pixel position°dONLNdkZHea(bHisAbs°dONLNdqZôe¡)Q:Boolean°dONLNdzZ
 e
„)á'; has been stuffed with absolute coords°dONLNd£dHo(lHbuttonCount°dONLNdØdôo≤)Q:Char°dONLNdµd
 o
Ÿ)á%; number of buttons currently pressed°dONLNd‹nHyu(vH    screenRes°dONLNdÊnôy¡)Q:Integer°dONLNdÔn
 y
Ë)á(; Pixels per inch on the current display°dONLNd
x6ÉJ(Ä6END;

°dONLNd
ö6¶
K*#<Most of the fields are fairly self-explanatory.  The fields °dONLNd
Yö
K¶
¯(£
K$labeled as private at the end of the°dONLNd
~¶6≤|(∞6
CrsrDevRec°dONLNd
àß|≥
E)F( are used to manage cursor acceleration °dONLNd
∞ß
E≥
¯)…!and shouldn't be modified by your°dONLNd
“≥6øá(º6software.  Some 
°dONLNd
‚≥áø
¯)QNof the usage of the other fields will be explained below in the description of°dONLNd1ø6Àfi(»6#the cursor device manager routines.
°dONLNdU◊6„Ò*Cursor Device Manager Routines°dONLNdtÚ6˛¶*CrsrDevNextDevice,New York°dONLNdÖÔ¶ˇ™)p
:°dONLNdá˛6


⁄(
6<Function CrsrDevNextDevice(VAR curDevice: CrsrDevPtr):OSErr;°dONLNdƒ
6
"ª*CrsrDevNextDevice()°dONLNd◊
ª
#¿)Ö
 °dONLNdÿ
¿
#
¯);can be used to index through the various devices the Cursor
°dONLNd
$6
0

(
-6+Device Manager is aware of.  You pass it a °dONLNd?
#


/
S)◊
CrsrDevPtr°dONLNdI
$
S
0
’)F; initialize this variable to °dONLNdg
#
’
/
Í)Çnil°dONLNdj
$
Í
0
¯) to
°dONLNdn
16
=(
:6advance to the °dONLNd}
1
=
 )I$first device in the list, then call °dONLNd°
0
 
<
•)°CrsrDevNextDevice()°dONLNd¥
1
•
=
¯)Ö repeatedly, each°dONLNdΔ
>6
JÖ(
G6time passing the °dONLNd◊
=Ö
IÀ)O
CrsrDevPtr°dONLNd·
>À
J˙)F as it was 
°dONLNdÏ
>˙
J
¯)/3last modified; when you have reached the end of the°dONLNd 
K6
WË(
T6)device list, the pointer returned in the °dONLNdI
JË
V
')≤    curDevice°dONLNdR
K
'
W
à)? parameter will be 0.
°dONLNdh
f6
r•(
o6CrsrDevNewDevice°dONLNdx
c•
s©)o
:°dONLNdz
r6
~n(
|6Function°dONLNdÇ
pn
Är)8
 °dONLNdÉ
rr
~
–)2CrsrDevNewDevice(VAR ourDevice: CrsrDevPtr):OSErr;°dONLNd∂
ã6
óL(
î6Call °dONLNdª
äL
ñ )CrsrDevNewDevice()°dONLNdÕ
ã 
ó˜)~ to create 
°dONLNdÿ
ã˜
ó
¯)-6a new cursor device and link it into the device chain.°dONLNd
ó6
£
÷(
†6YThe new device record will be initialized with values representing a standard one-button 
°dONLNdh
ó
÷
£
¯(
†
÷mouse;°dONLNdo
§6
∞Å(
≠6you should call °dONLNd
£Å
Ø
))KCrsrDevSetAcceleration()°dONLNdó
§
)
∞
á)® for the device after 
°dONLNd≠
§
á
∞
¯)^creating it. A pointer to°dONLNd«
±6
Ωfi(
∫6&the created device is returned in the °dONLNdÌ
∞fi
º
)®    ourDevice°dONLNdˆ
±

Ω
I)?
 variable.
°dONLNd

…6
’
(
“6+New cursor devices are created for all ADB °dONLNd,
…

’
¯)ÿ.address 3 devices. This routine should only be°dONLNd[
’6
·
·(
fi6Xneeded by devices which are connected though some other method, such as the serial port.
°dONLNd¥
Ì6
˘º*CrsrDevDisposeDevice:°dONLNd 
˘6
”*
;Function CrsrDevDisposeDevice(ourDevice: CrsrDevRec):OSErr;°dONLNd6
◊*[This routine disposes of a cursor device and unlinks it from the device chain.  This isn't 
°dONLNda
◊
¯(
◊needed°dONLNdh6)ô(&6by most developers, 
°dONLNd|ô)
¯)cDbut could be useful for non-ADB devices which might be connected and°dONLNd¡)65w(26
disconnected.
°dONLNdœA6Mà*CrsrDevMove:°dONLNd‹M6Y
c*
+Function CrsrDevMove(ourDevice: CrsrDevRec;°dONLNdY6e
õ*3                     deltaX,deltaY: LongInt):OSErr;°dONLNd<q6}ë*
CrsrDevMove()°dONLNdIrë~·)[ accumulates the °dONLNdZq·}
)PdeltaX°dONLNd`r
~
")* and 
°dONLNdeq
"}
L)deltaY°dONLNdkr
L~
¯)*" values into the recorded movement°dONLNdé~6ä
Æ(á6Uof the device; the next time the cursor position is calculated, these deltas will be 
°dONLNd„~
Æä
¯(á
Æfed through the°dONLNdÛä6ñ
k(ì6Bacceleration algorithm and used to move the cursor.  This routine 
°dONLNd    5ä
kñ
¯(ì
kshould be called by a relative°dONLNd    Tñ6¢Á(ü6(device driver with the data it receives 
°dONLNd    |ñÁ¢
¯)±<from its device, even if the deltas are both zero; this lets°dONLNd    π¢6Æ
®(´6Gthe acceleration algorithm properly calculate the appropriate motion.  °dONLNd
¢
®Æ
¯(´
®This routine is ¿4¿
˘

(’610)
 of 18)µ9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse+flHardwareˇHRˇˇˇˇˇRH

HR,Times

.+Z-Developer Technical Support(-
ÁJanuary 1994 /X/
°dONLNd<ZH(EZ^automatically called by the default driver for address 3 devices; you would only need to call 
°dONLNd^<H(Eit if°dONLNddHZTÛ(QZyou were using a custom driver.
°dONLNdÑ`Zlª*CrsrDevMoveTo:,
Courier°dONLNdìlZx
ï*
-Function CrsrDevMoveTo(ourDevice: CrsrDevRec;°dONLNd¡xZÑ
±*1                       absX,absY: LongInt):OSErr;°dONLNdÛêZú√*CrsrDevMoveTo()°dONLNd
ë√ù
é)i. sets the absolute position of the cursor to (°dONLNd
0ê
éú
™)ÀabsX°dONLNd
4ë
™ù
±), °dONLNd
6ê
±ú
Õ)absY°dONLNd
:ë
Õù
)).  The 
°dONLNd
Bë
ù)#    next time°dONLNd
LùZ©»(¶Zthe cursor position is °dONLNd
cù»©)nCcalculated, it will be moved to this absolute location.  This would°dONLNd
ß©Zµ
‡(≤ZTnormally be used by a driver for an absolute pointing device to position the cursor.
°dONLNd
¸¡ZÕ≠*
CrsrDevFlush:°dONLNd
ÕZŸ
ø*
3Function CrsrDevFlush(ourDevice: CrsrDevRec):OSErr;
°dONLNd>ÂZÒº*CrsrDevFlush()°dONLNdLʺÚ
Î)b@ causes the acceleration and motion algorithms to flush out all °dONLNdåÊ
ÎÚ(Ô
Îtheir error°dONLNdòÚZ˛
(˚Z&collection and motion deltas into the °dONLNdæÚ
˛)∏6cursor position; it indicates that your device is done
°dONLNdı˛Z


%(
Z(moving temporarily.  This may be useful °dONLNd˛
%

)À0for devices which can tell when they become idle
°dONLNdN

Z

™(
ZH(such as a stylus pointing device); if they call this routine when they °dONLNdñ


™
(

™become idle, it ensures°dONLNdÆ
Z
"
(
Z$that all unused motion data will be °dONLNd“


")≤6worked into the cursor position at the next time it is°dONLNd    
"Z
.å(
+Zcalculated.
°dONLNd
=Z
Iµ*CrsrDevButtons,New York°dONLNd#
:µ
Jπ)[
:°dONLNd%
IZ
U
ú(
SZ.Function CrsrDevButtons(ourDevice: CrsrDevRec;°dONLNdT
UZ
a
ï*-                        buttons: Char):OSErr;°dONLNdÇ
mZ
y *CrsrDevButtons()°dONLNdí
n 
z
 )p handles posting °dONLNd£
m
 
y
Q)VmouseUp°dONLNd™
n
Q
z
l)1 and °dONLNdØ
m
l
y
´)    mouseDown°dONLNd∏
n
´
z
∞)?
 °dONLNdπ
n
∞
z)events and also deals
°dONLNdœ
{Z
ás(
ÑZwith °dONLNd‘
{s
á
¥)@debouncing mouse clicks.  Pass the current button status in the °dONLNd
z
¥
Ü
Â(
Ñ
¥buttons°dONLNd
{
Â
á)1 parameter,°dONLNd'
áZ
ìÌ(
êZgoing from bit 0 is button 0 °dONLNdD
áÌ
ì)ì;to bit 7 representing button 7.  For each button, a one bit°dONLNdÄ
ìZ
ü
(
úZ'represents down, a zero bit represents 
°dONLNdß
ì

ü)∂5up.  This routine debounces mouse clicks to keep them°dONLNd›
üZ
´
¥(
®ZKfrom looking like double clicks; if the button goes down less than 2 ticks 
°dONLNd(
ü
¥
´(
®
¥after coming up, then°dONLNd>
¨Z
∏k(
µZthe °dONLNdB
´k
∑™)    mouseDown°dONLNdK
¨™
∏¬)? will 
°dONLNdQ
¨¬
∏)Ebe ignored. Button up events are never ignored to avoid problems such°dONLNdó
∏Z
ƒ
˛(
¡ZXas continuous scrolling which are confusing and difficult for the user to deal with.  A °dONLNdÔ
∏
˛
ƒ(
¡
˛device
°dONLNdˆ
ƒZ
–
(
ÕZ)driver should call this routine any time °dONLNd
ƒ

–)ø6it gets a data packet; this routine deals with keeping°dONLNdV
–Z
‹
ï(
ŸZ=track of whether the button state has changed.  This routine °dONLNdì
–
ï
‹(
Ÿ
ïautomatically calls routines°dONLNd∞
›Z
Èú(
ÊZinstalled with °dONLNdø
‹ú
Ë
)BCrsrDevButtonOp()°dONLNd–
›

È
)w
.
°dONLNd“
¯Z–(
ZCrsrDevButtonDown°dONLNd„
ı–‘)v
:°dONLNdÂZ
‚(Z8Function CrsrDevButtonDown(ourDevice: CrsrDevRec):OSErr;°dONLNdZ(fl*CrsrDevButtonDown()°dONLNd1fl)
)Ö     posts a °dONLNd:
(
E)'    mouseDown°dONLNdC
E))?. event if this is the first button to go down 
°dONLNdq))…for°dONLNdu)Z5
ú(2ZFthis device.  It is called by the standard button operation routines; °dONLNdª)
ú5(2
úyou should need to call it°dONLNd÷5ZA
F(>Z2only if you use a custom button operation routine.
°dONLNd        PZ\¿*CrsrDevButtonUp°dONLNd    M¿]ƒ)f
:°dONLNd    \Zh
‘(fZ6Function CrsrDevButtonUp(ourDevice: CrsrDevRec):OSErr;°dONLNd    QtZÄ—*CrsrDevButtonUp()°dONLNd    bu—Å)w posts 
°dONLNd    iuÅ˘)a °dONLNd    kt˘Ä
*)    mouseUp°dONLNd    ru
*Å)15 event if this is the last button to come up for this°dONLNd    ®ÅZç
P(äZ7device.  It is called by the standard button operation 
°dONLNd    flÅ
Pç)ˆ,routines; you should need to call it only if°dONLNd
çZô
$(ñZ*you use a custom button operation routine. ¿X¿

*?9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse(’11)
 of 18(ÎZHardwareˇ^HRˇˇˇˇˇRH

HR,Times

.+6-Macintosh Technical Notes /4/
˘

°dONLNd<6Hü*CrsrDevButtonOp:,
Courier°dONLNdH6T
Ô*
?Function CrsrDevButtonOp(ourDevice: CrsrDevRec; btnNo: Integer;°dONLNdQT6`
Ô*?                         opCode: Integer; data: LongInt):OSErr;°dONLNdël6x≠*CrsrDevButtonOp()°dONLNd¢m≠y
")w sets a new operation °dONLNd∏m
"y
¯)u*to be associated with a particular button.°dONLNd‰y6ÖY(É6btnNo°dONLNdÈzYÜ\)#
 
°dONLNdÍz\ÜÁ)may range from 0 to 7, and °dONLNd
yÁÖ
)ãopCode°dONLNd
z
Ü
¯)*1 specifies what operation to use.  The data field°dONLNd
=á6ì∞(ê6specifies a parameter for °dONLNd
Wá∞ì
h)z&the operation you are setting for the °dONLNd
}Ü
hí
√)∏
kButtonCustom°dONLNd
äá
Ó
¯)[ operation.°dONLNd
óî6†K(ù6The °dONLNd
õìKüu)opCode°dONLNd
°îu†
])*0 parameter may have one of the following values:°dONLNd
“¨Z∏ß(∂ZkButtonNoOp°dONLNd
fi¨Í∏
(µÍ    No action°dONLNd
È∏Zƒÿ(¬ZkButtonSingleClick°dONLNd
¸∏̓
Q(¡ÍNormal mouse button°dONLNdƒZ–ÿ(ŒZkButtonDoubleClick°dONLNd$ƒÍ–
ª(ÕÍ,Click, release, and click again when pressed°dONLNdR–Z‹ (⁄ZkButtonClickLock°dONLNdc–Í‹
ó(ŸÍ%Click on press, release on next press°dONLNdä‹ZË—(ÊZkButtonCharStroke°dONLNdú‹ÍË
d(ÂÍUnimplemented, reserved°dONLNdµËZÙÿ(ÚZkButtonAppleScript°dONLNd»ËÍÙ
d(ÒÍUnimplemented, reserved°dONLNd·ÙZ
µ(˛Z
kButtonCustom°dONLNdÔÙÍ

«(˝Í/Call a custom procedure; data holds its address°dONLNd!

6
g(
6
Using the °dONLNd+
g
¶)1    btnCustom°dONLNd4

¶

ò)?3 operation will cause a procedure whose address is 
°dONLNdg


ò

¯)Úpassed in data to be°dONLNd|
6
%Ö(
"6called whenever 
°dONLNdå
Ö
%
¯)OMthis button changes state.  The procedure takes the following parameters: the°dONLNd⁄
&6
2~(
/6address of the °dONLNdÈ
%~
1ƒ)H
CrsrDevRec°dONLNdÛ
&ƒ
2
j)F$ record for its device is passed in °dONLNd
&
j
2
í)¶    register °dONLNd 
%
í
1
†)(A2°dONLNd"
&
†
2
¯); the button being°dONLNd5
36
?–(
<6#pressed or released is in register °dONLNdX
2–
>fi)öD3°dONLNdZ
3fi
?˝).  The 
°dONLNda
3˝
?
¯)5new state of the button will already have been filled°dONLNdó
@6
L∑(
I6into the buttons field in the °dONLNdµ
?∑
K˝)Å
CrsrDevRec°dONLNdø
@˝
L
')F    , so you 
°dONLNd»
@
'
L
¯)*,may use that flag to determine if the button°dONLNdı
M6
Y^(
V6    is being 
°dONLNd˛
M^
Y
o)(9clicked or released.  Your routine may destroy registers °dONLNd7
L
o
X
}(
V
oD0°dONLNd9
M
}
Y
Ö), °dONLNd;
L
Ö
X
ì)D2°dONLNd=
M
ì
Y
õ), °dONLNd?
L
õ
X
©)A0°dONLNdA
M
©
Y
¬) and °dONLNdF
L
¬
X
–)A1°dONLNdH
M
–
Y
¯)    ; it must°dONLNdR
Y6
e∂(
b6preserve all other registers.°dONLNdp
r6
~R*The °dONLNdt
qR
}…)kButtonCharStroke°dONLNdÖ
r…
~)w and °dONLNdä
q
}
n)'kButtonAppleScript°dONLNdú
r
n
~
¯)~ operations are currently°dONLNd∂
~6
ä
z(
á6Cunimplemented and will simply cause the button press to be ignored.
°dONLNd˙
ñ6
¢ß*CrsrDevSetButtons:°dONLNd

¢6
Æ
ç*
1Function CrsrDevSetButtons(ourDevice: CrsrDevRec;°dONLNd?
Æ6
∫
∞*6                           numButtons: Integer):OSErr;°dONLNdv
Δ6
“ª*CrsrDevSetButtons()°dONLNdâ
ǻ
”
ú)Ö0 allows you to set the number of buttons on the 
°dONLNdπ
«
ú
”
¯)·device specified by°dONLNdÕ
”6
flu(
›6    ourDevice°dONLNd÷
‘u
‡Ñ)? to °dONLNd⁄
ӄ
fl )
numButtons°dONLNd‰
‘ 
‡Œ)F
.
°dONLNdÊ
Ô6
˚Ω(
¯6CrsrDevSetAcceleration,New York°dONLNd¸
ÏΩ
¸¡)á
:°dONLNd˛
˚6
∞(66Function CrsrDevSetAcceleration(ourDevice: CrsrDevRec,°dONLNd56=*
 °dONLNd8~
’)H1                      acceleration: Fixed):OSErr;°dONLNdj6+fi()6CrsrDevSetAcceleration()°dONLNdÇ fi,
p)® lets you set the acceleration °dONLNd° 
p,
¯)ífor the device specified by
°dONLNdΩ,68u(66    ourDevice°dONLNdΔ-u9Û)? to the value specified by °dONLNd·,Û8
G)~acceleration°dONLNdÌ-
G9
â)T, where 0 ≤ °dONLNd˘,
â8
›)Bacceleration°dONLNd-
›9
¯)T ≤ 1.°dONLNd96Eo(B6The Cursor 
°dONLNd9oE
¯)9RDevice Manager will build an acceleration table for the device based on its device°dONLNdjE6Q
i(N6DID or device class and the desired acceleration value.  For details 
°dONLNdÆE
iQ
¯(N
ion acceleration resources, see°dONLNdÕR6^
([6/"Acceleration Tables" below.  The acceleration 
°dONLNd¸R
^
P)fl
table set by °dONLNd        Q
P]
¯);CrsrDevSetAcceleration()°dONLNd    "_6k
Œ(h6[is found by interpolating the tables stored in the appropriate acceleration resource.  All 
°dONLNd    }^
Œj
¯(h
Œ'accl'°dONLNd    Ñk6w
"(t62resources in the resource chain or in the ROM are 
°dONLNd    ∂k
"w
¯)Ï,searched looking for the one applying to the°dONLNd    „x6Ѷ(Å6specified device, so a °dONLNd    ˙x¶Ñ
0)pcontrol panel which called °dONLNd
w
0É
ÿ)äCrsrDevSetAcceleration()°dONLNd
-x
ÿÑ
¯)® could°dONLNd
4Ö6ëx(é6implicitly use °dONLNd
CÑxê¢)B'accl'°dONLNd
IÖ¢ë
≥)*; resources stored within the control panel's resource fork. ¿4¿
˘

(’612)
 of 18)µ9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse+flHardwareˇûHRˇˇˇˇˇRH

HR,Times

.+Z-Developer Technical Support(-
ÁJanuary 1994 /X/

°dONLNd?ZKÕ(HZCrsrDevDoubleTime,New York°dONLNd<ÕL—)s
:,
Courier°dONLNdKZW
±(UZ1Function CrsrDevDoubleTime(ourDevice: CrsrDevRec;°dONLNdEWZc
Δ*4                           duration: LongInt):OSErr;°dONLNdzoZ{fl*CrsrDevDoubleTime()°dONLNdçpfl|
)Ö6 lets you set the double-click time associated with a °dONLNd√p
|(y

particular°dONLNdŒ|Zà
(ÖZ*device.  The duration parameter specifies 
°dONLNd¯|
à)ƒ7the time, in ticks, to use as the double-click time for°dONLNd
0àZî
r(ëZ;this device.  An application could be written to check the °dONLNd
kà
rî(ë
r$double-click time for the particular°dONLNd
êîZ†
(ùZ&device in checking for a double-click.
°dONLNd
∑ØZª‘*CrsrDevUnitsPerInch°dONLNd
 ¨‘ºÿ)z
:°dONLNd
êZ«
ø(≈Z3Function CrsrDevUnitsPerInch(ourDevice: CrsrDevRec;°dONLNd«Z”
‘*6                             resolution: Fixed):OSErr;°dONLNd7flZÎÌ*CrsrDevUnitsPerInch()°dONLNdL‡ÌÏ)ì
 
°dONLNdM‡Ï)Blets you set the resolution of a particular device to its physical°dONLNdêÏZ¯
L(ıZ5resolution, in units per inch.  For devices adhering 
°dONLNd≈Ï
L¯)Ú*to the Apple extended mouse protocol, this°dONLNd¯Z
„(

Zcall shouldn't  be needed, as 
°dONLNd¯„
)âAthe resolution can be read from the device's register 1; however,°dONLNdP
Z

ø(

ZKthis call might be made by a driver for a device which doesn't use the ADB.
°dONLNdú
Z
(…*Acceleration Tables
°dONLNd∞
5Z
A∑*Acceleration tables °dONLNdƒ
5∑
A
T)] are stored in resources of type °dONLNd‰
4
T
@
~)ù'accl'°dONLNdÍ
5
~
A)*, which have the following Rez°dONLNd    
AZ
Më(
JZdescription:
    °dONLNd
YZ
dõ*
type 'accl' {°dONLNd%
cl
n∑+
literal longInt°dONLNd5
c
 
n
Ÿ)¥%/* Device identifier or device class °dONLNd[
c

n)Í*/°dONLNd`
m~
xƒ(
u~classAbsolute,°dONLNdo
m
 
x
¢)¢/* A flat-response device °dONLNdä
m

x)Í*/°dONLNdè
w~
ǵ(
~classMouse,°dONLNdõ
w
 
Ç
ª)¢/* Mechanical or optical mouse °dONLNdª
w

Ç)Í*/°dONLNd¿
Å~
å…(
â~classTrackball;°dONLNd–
Å
 
å
a)¢
/* Trackball °dONLNdfi
Å

å)Í*/°dONLNdÂ
ïl
†
(
ùlinteger = $$CountOf(AcclTable);°dONLNd
ï
 
†
œ)¥#/* Number of tables for this device°dONLNd)
ï

†)Í*/°dONLNd-
ül
™¡(
ßlarray AcclTable {°dONLNd?
ü
 
™
˜)¥+/* Entries sorted by first value; must have°dONLNdk
ü

™)Í*/°dONLNdq
©
 
¥
∂(
±
 /* at least 0.0 and 1.0 tables°dONLNdê
©

¥)Í*/°dONLNdï
≥~
æÁ(
ª~unsigned hex longint;°dONLNd´
≥
 
æ)¢1/* Acceleration provided by this table (Fixed) */°dONLNd‚
«~
“
(
œ~integer = $$CountOf(AcclPoint);°dONLNd
«
 
“
˜)¢+/* Number of control points for this device°dONLNd.
«

“)Í*/°dONLNd3
—~
‹Ï(
Ÿ~wide array AcclPoint {°dONLNdJ
—
 
‹
˜)¢+/* Entries sorted by first value; implicit °dONLNdv
—

‹)Í*/°dONLNd}
€
 
Ê
¸(
„
 ,/* first entry (0.0, 0.0); at least one more°dONLNd™
€

Ê)Í*/°dONLNd±
Â
 

(
Ì
 /* entry required. °dONLNd≈
Â

)Í*/°dONLNdÀ
Ôê
˙˘(
˜êunsigned hex longint;°dONLNd·
Ô
 
˙
¸)ê,/* Device speed (inches per second) (Fixed) °dONLNd
Ô

˙)Í*/°dONLNd
˘ê˘(
êunsigned hex longint;°dONLNd*
˘
 
¸)ê,/* Cursor speed (inches per second) (Fixed) °dONLNdW
˘
)Í*/°dONLNd\~à(~};°dONLNd`
lv(l};°dONLNdcZ"d(Z};
°dONLNdf.Z:…*The identifier for this °dONLNd~-…9Û)o'accl'°dONLNdÑ.Û:
b)* resource is stored in °dONLNdõ.
b:)o&the first long word; this is either an°dONLNd¬:ZFÑ(DZOSType°dONLNd»;ÑG
Ò)*L four character device identifier or an integer value specifying the device °dONLNd;
ÒG(D
Ò    class. In
°dONLNdGZS¯(PZ#either case, the device's identity °dONLNdAG¯S)û<is generally read from the device's register 1, as described°dONLNd~SZ_
e(\Z6below in the section "Extended Apple Mouse Protocol." 
°dONLNd¥S
e_(\
e%The Cursor Device Manager first tries°dONLNd⁄_ZkÎ(hZto match against the specific °dONLNd¯_Îk)ë=device identifier, then against the more general class.  Each°dONLNd    6kZwÑ(uZ'accl'°dONLNd    <lÑxÚ)* resource can contain a 
°dONLNd    TlÚx)n@number of acceleration tables for different acceleration values;°dONLNd    ïxZÑ
d(ÅZ6each table contains a number of entries which match a °dONLNd    Àx
dÑ(Å
d'particular device speed to a particular
°dONLNd    ÛÖZëµ(éZcursor speed.  An °dONLNd
ѵêfl)['accl'°dONLNd
Öflë
˛)*= resource must contain at least two acceleration tables, one °dONLNd
HÖ
˛ë(é
˛for an°dONLNd
OëZù
5(öZ0acceleration of 0.0 and one for an acceleration 
°dONLNd
ë
5ù)€0value of 1.0.  When an acceleration value is set°dONLNd
∞ùZ©
ˆ(¶ZWfor a particular device, the acceleration table is calculated by interpolating between °dONLNdù
ˆ©(¶
ˆthe two ¿X¿

(’Z9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse(’13)
 of 18(ÎZHardwareˇ‰HRˇˇˇˇˇRH

HR,Times

.+6-Macintosh Technical Notes /4/
˘
°dONLNd=6I£*nearest tables from the ,
Courier°dONLNd<£HÕ)m'accl'°dONLNd=ÕI–)*
 
°dONLNd=–I
¯)@resource.  There is an implicit entry in each acceleration table°dONLNd`I6U
(R6/of (0.0, 0.0), which indicates that the cursor 
°dONLNdèI
U
¯)’1should not move if the device does not.  At least°dONLNd¡U6aŒ(^6"one additional entry is required; 
°dONLNd„UŒa
¯)ò>the Cursor Device Manager will use the table entries to figure°dONLNd
"a6m“(j6the cursor movement by using °dONLNd
?a“m
¯)ú9the device movement to interpolate based on the specified°dONLNd
ym6yØ(v6movement control points.
°dONLNd
íÖ6ë
,*)Availability Of The Cursor Device Manager°dONLNd
ºù6©
c*5The Cursor Device Manager was introduced in the ROMs °dONLNd
Òù
c©
¯(¶
cof Macintoshes introduced in
°dONLNd©6µ
ú(≤6HFebruary, 1993.  It may be installed via software on any Macintosh.  To °dONLNdV©
úµ
¯(≤
úcheck to see if the°dONLNdj∂6¬
k(ø6@Cursor Device Manager is available, you should use the standard 
°dONLNd™µ
k¡
Δ(ø
k
TrapAvailable°dONLNd∑∂
Δ¬
¯)[ routine to°dONLNd√√6œ
ò(Ã6Lcheck to see if its trap is implemented.  The Cursor Device Manager trap is °dONLNd¬
òŒ
ª(Ã
ò$AADB°dONLNd√
ªœ
¬)#, 
°dONLNd√
¬œ
¯)making it a°dONLNd"–6‹≤(Ÿ6toolbox trap, trap number °dONLNd<œ≤€Œ)|$2DB°dONLNd@–Œ‹“)
.
°dONLNdBË6ÙÉ(Ò6
Compatibility°dONLNdP
6

—*WWhen the Cursor Device Manager is installed, all Apple mouse drivers use its interface 
°dONLNdß

—

¯(
    
—to move°dONLNdØ

6
·(
6$the cursor; this means that the low °dONLNd”

·

^)´memory globals such as °dONLNdÍ

^

Å)}Mouse°dONLNdÔ


Å

ú)# and °dONLNdÙ

ú

‘)RawMouse°dONLNd¸


‘

¯)8 are no°dONLNd
6
%x(
"6
longer used. °dONLNd
x
%
¯)BJ While a compatibility mode keeps drivers which still modify these globals°dONLNd\
%6
1
´(
.6Ocontinue to work, the cursor position can no longer be read from these globals.

°dONLNd¨
=6
Lï*
Apple Devices
°dONLNd∫
X6
d·*Classic Apple Mouse Protocol°dONLNd◊
p6
|
*.The original Apple mouse protocol has allowed 
°dONLNd
p

|
¯)‚.for mice with a resolution of 100 or 200 units°dONLNd4
|6
àÄ(
Ö6per inch with 7 
°dONLNdD
|Ä
à
¯)JKbit accumulation of relative movement with one or two buttons. Handler ID 1°dONLNdê
à6
îg(
ë6    was used °dONLNdô
àg
î
¯)1Sto indicate 100 cpi operation; handler 2 to indicate 200 cpi operation. All data is°dONLNdÌ
î6
†
3(
ù67transferred through register 0 in the following format:†Ç†å


¨6
˙    1
∏M
 
m    ˇˇˇˇˇˇˇˇ0
∑L
À
n"
∑^

"
∏q"
∏É"
∏ï"
∏ß"
∏π"
∏À"
∑‹"
∑Ó

"
∏

"
∏
"
∏
%"
∏
7"
∏
I"
∏
[°ñ
°öˇ˝


≠P
π].
m
ƒm
ƒ°dONLNdˇˇ+15†ó°ñ
°öˇ˝


≠b
πo°dONLNdˇˇ)14†ó°ñ
°öˇ˝


≠–
π◊°dONLNdˇˇ)n
8†ó°ñ
°öˇ˝


≠‚
πÈ°dONLNdˇˇ)
7†ó°ñ
°öˇ˝


≠Ù
π˚°dONLNdˇˇ)
6†ó°ñ
°öˇ˝


≠
`
π
g°dONLNdˇˇ)l
0†ó°ñ
°öˇ˝    


≠7
πK°dONLNdˇˇ(
∂8Bit:†ó


¨6
˙"
”
d    "
”
R    "
”
@    "
”
.    "
”
    "
”

    "
”¯    !
‹
"
”Ê!
Ó
"
”‘- h
 
V#¡"
”¬-"
”∞-"
”û-"
ӌ-"
”z-"
”h-°ñ
°öˇ¸#


à
—°dONLNdˇˇ(
âButton pressed†ó°ñ
°öˇ¸$


˙
à
‘&¿°dONLNdˇˇ(
âY motion value†ó°ñ
°öˇ¸7


Ë
à
Ù
˘ÕÄ°dONLNdˇˇ(
Ò
âOptional second button†ó°ñ
°öˇ¸$


÷
à
‚
‘»°dONLNdˇˇ(
fl
âX motion value†ó†ç†É

HR
.



°dONLNd%%ù1
ê(.ù(Figure 1–Classic Mouse Register 0 Format°dONLNdN=6I
#(F62Where relative motion in each axis is accumulated 
°dONLNdÄ=
#I
¯)Ì,until fetched with a talk register 0 command°dONLNd≠I6U
t(R6Csent by the host. The X value represents left-to-right motion, the °dONLNdI
tU
¯(R
tY value holds accumulated°dONLNd
U6a´(^6forward-to-back motion.
°dONLNd"m6yÏ*Extended Apple Mouse Protocol°dONLNd@Ö6ë±*In order to be able to take 
°dONLNd\Ö±ë
¯){Badvantage of the higher movement resolution support available with°dONLNdüë6ù
Æ(ö6Mthe Cursor Device Manager, an extended mouse protocol has been defined; this 
°dONLNdÏë
Æù
¯(ö
Æallows a device°dONLNd¸ù6©
H(¶68to communicate up to 16 bits of movement data with each 
°dONLNd4ù
H©
¯(¶
H$polling and allows a standard device°dONLNdY©6µ›(≤6$to communicate the state of up to 8 
°dONLNd}©›µ
¯)ß:buttons. In addition, the new format allows each device to ¿4¿
˘

(’614)
 of 18)µ9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse+flHardwareˇåHRˇˇˇˇˇRH

HR,Times

.+Z-Developer Technical Support(-
ÁJanuary 1994 /X/
°dONLNd<ZH
ƒ(EZMcommunicate its exact type, resolution and class. This new format applies to 
°dONLNdM<
ƒH(E
ƒall relative devices°dONLNdbHZT˚(QZ#at default address 3, handler ID 4.
°dONLNdÜ`Zl
»*JDuring startup or after a reset of the ADB bus, devices which power up at °dONLNd–`
»l(i
»default address 3
°dONLNd‚lZx
≈(uZLwith handler ID 1 will be switched to handler ID 4 with a listen register 3 °dONLNd
.l
≈x(u
≈command.  If the°dONLNd
?xZÑ
‰(ÅZTdevice accepts the switch and reports the new handler ID of 4 back in response to a 
°dONLNd
ìx
‰Ñ(Å
‰
talk register°dONLNd
°ÑZê
ö(çZ=3 command, all subsequent communication with the device will °dONLNd
ބ
öê(ç
öbe assumed to follow the
°dONLNd
˜êZú
%(ôZ)extended mouse protocol.  Currently, the °dONLNd ê
%ú)À-ADB manager makes an additional check, making
°dONLNdNúZ®
"(•Z,sure that a talk register 1 returns 8 bytes °dONLNdzú
"®)»4(the format of register 1 is specified below).  If a°dONLNdØ®Z¥
¬(±ZMdevice accepts a handler ID change but does not return 8 bytes from register 
°dONLNd¸®
¬¥(±
¬1, it is assumed to°dONLNd¥Z¿‹(ΩZnot actually be an extended 
°dONLNd,¥‹¿)ÇBmouse protocol device and is switched back to its original handler°dONLNdo¿ZÃj(…ZID.°dONLNdsÿZ‰k*All 
°dONLNdwÿk‰)Vmovement and button data still passes through register 0, which can now hold between 2°dONLNdŒ‰Z‹(ÌZand 5 bytes, where 2 bytes 
°dONLNdȉ‹)ÇEprovides the device with the data transfer capability of the original°dONLNd/Z¸
∞(˘ZGmouse protocol and additional bytes allow added resolution and buttons.
°dONLNdw
Z

L*1Bytes 0 and 1 of register 0 have the same format °dONLNd®

L
)Ú*as they did in the classic mouse protocol,
°dONLNd”
Z
 
ü(
ZCcommunicating the state of the first two buttons and the low order °dONLNd

ü
 (

ü7 bits of the accumulated°dONLNd0
 Z
,
?(
)Z0motion in the X and Y axes.  There can be up to 
°dONLNd`
 
?
,)Â.3 bytes of additional information: each one of°dONLNdè
,Z
8
(
5Z these bytes can communicate the °dONLNdØ
,

8)¶6state of 2 more buttons and add 3 higher order bits of°dONLNdÊ
8Z
D
ƒ(
AZNresolution to each of the X and Y axes. The format of each additional byte is:†Ç†å


Pò
Ω
›    1
\Ø
n
?    ˇˇˇˇˇˇˇˇ0
[Æ
o
@"
[¿

"
\”"
\Â"
[ˆ"
[


"
\
"
\
-°ñ
°öˇ˝    


Qô
]≠.
m
Em
E°dONLNdˇˇ+@Bit:†ó°ñ
°öˇ˝


Q¥
]ªÅÄ°dONLNdˇˇ)
7†ó°ñ
°öˇ˝


QΔ
]ÕÅÄ°dONLNdˇˇ)
6†ó°ñ
°öˇ˝


Q
2
]
9ÅÄ°dONLNdˇˇ)l
0†ó°ñ
°öˇ˝


Q¸
]
ÅÄ°dONLNdˇˇ(
Z˝
3†ó°ñ
°öˇ˝


Q

]
ÅÄ°dONLNdˇˇ)
2†ó°ñ
°öˇ˝


QÍ
]ÒÅÄ°dONLNdˇˇ(
ZÎ
4†ó


Pò
Ω
›"
Ä
?"
w
6    "
w
$    "
w
    "
w
#Q"
wÓ- 
§ 
§
Q"
w∏?!
∂
Q"
w‹-"
w -°ñ
°öˇ¸4


∞
Z
º
Δ°dONLNdˇˇ+p_First additional button†ó°ñ
°öˇ¸?


û
Z
™
‹'¿°dONLNdˇˇ(
ß
[Additional Y motion value†ó°ñ
°öˇ¸;


å
Z
ò
”!¿°dONLNdˇˇ(
ï
[Second additional button†ó°ñ
°öˇ¸?


z
Z
Ü
‹Ä°dONLNdˇˇ(
É
[Additional X motion value†ó†ç†É

HR
.



°dONLNd5
…[
’(
“[JFigure 2–Format Of Additional Register 0 Bytes For Extended Mouse Protocol°dONLNdÄ
·Z
Ì€(
ÍZAs a specific example, in a 
°dONLNdú
·€
Ì)ÅBmaximal 5 byte transmission, the data would be transferred in this°dONLNdfl
ÌZ
˘|(
ˆZformat:°dONLNdÁ«·+mBit #:°dONLNdÓˆ))
7°dONLNd

)
6°dONLNdÚ
)
/)
5°dONLNdÙ
F
L)
4°dONLNdˆ
c
i)
3°dONLNd¯
Ä
Ü)
2°dONLNd˙
ú
¢)
1°dONLNd¸
π
ø)
0"‰°dONLNdˇø·(øByte 0:°dONLNdÌ˘).b0°dONLNd


)y06°dONLNd
#
5)y05°dONLNd
@
R)y04°dONLNd
]
o)y03°dONLNd
z
å)y02°dONLNd
ñ
®)y01°dONLNd"
≥
≈)y00"≥0"‰"Â"
"

"
"
"
:"
;"
W"
X"
t"
u"
ê"
ë"
≠"
Æ"‰°dONLNd'ø*·('øByte 1:°dONLNd/Ì*˘).b1°dONLNd2
*
)x06°dONLNd6
#*
5)x05°dONLNd:
@*
R)x04°dONLNd>
]*
o)x03°dONLNdB
z*
å)x02°dONLNdF
ñ*
®)x01°dONLNdJ
≥*
≈)x00"‰°dONLNdO*ø6·(3øByte 2:°dONLNdW*Ì6˘).b2°dONLNdZ*
6
)y09°dONLNd^*
#6
5)y08°dONLNdb*
@6
R)y07°dONLNdf*
`6
l) b3°dONLNdi*
z6
å)x09°dONLNdm*
ñ6
®)x08°dONLNdq*
≥6
≈)x07"*‰°dONLNdv6øB·(?øByte 3:°dONLNd~6ÌB˘).b4°dONLNdÅ6
B
)y12°dONLNdÖ6
#B
5)y11°dONLNdâ6
@B
R)y10°dONLNdç6
`B
l) b5°dONLNdê6
zB
å)x12°dONLNdî6
ñB
®)x11°dONLNdò6
≥B
≈)x10"6‰°dONLNdùBøN·(KøByte 4:°dONLNd•BÌN˘).b6°dONLNd®B
N
)y15°dONLNd¨B
#N
5)y14°dONLNd∞B
@N
R)y13°dONLNd¥B
`N
l) b7°dONLNd∑B
zN
å)x15°dONLNdªB
ñN
®)x14°dONLNdøB
≥N
≈)x13"B‰
°dONLNd≈Z£f
”(c£3Table 2–Format Of A 5 Byte Register 0 Data Transfer°dONLNd˘rZ~Ç({ZWhere b°dONLNdrÇ~à)(
n°dONLNd
rà~Û) indicates the status of 
°dONLNdrÛ~
)kbutton °dONLNd!r
~
)"
n°dONLNd"r
~
:) and x°dONLNd(r
:~
D)aa°dONLNd*r
D~
\)
 or y°dONLNd/r
\~
h)bb°dONLNd1r
h~
Ê) indicates the value of bit °dONLNdMr
Ê~
)~aa°dONLNdOr
~)
 or °dONLNdSr~)bb°dONLNdUr~) of°dONLNdY~Zäƒ(áZthe X or Y movement. ¿X¿

*N9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse(’15)
 of 18(ÎZHardwareˇ‡HRˇˇˇˇˇRH

HR,Times

.+6-Macintosh Technical Notes /4/
˘
°dONLNd<6H
M*6In addition, register 1 is used in the extended mouse °dONLNd6<
MH
¯(E
M protocol to provide some general°dONLNdWH6T
«(Q6Winformation about the device.  Register 1 is 8 bytes long and is formatted in this way:°dONLNdØ`Ülπ+P
Byte range°dONLNd∫`
%l
G)üFormat"lyK"`≈"l≈ lΔl
•°dONLNd¬mòy®(vò0-3°dONLNdΔm y
;)2Unique device identifier"lyK"l≈ lΔl
•"m≈°dONLNd‡yòÖ®(Çò4-5°dONLNd‰y Ö
Y)2Device resolution in units/inch"yšdONLNd
Öùë£(éù
6°dONLNd
Ö ë
Ç)-&Device class (Mouse, trackball, etc.…)"Ö≈°dONLNd
/ëùù£(öù
7°dONLNd
1ë ù
?)-Number of buttons (0-8)"ë≈
°dONLNd
K©xµ
∂(≤x4Table 3–Format Of Extended Mouse Protocol Register 1
°dONLNd
Ä¡6Õ
5( 66The unique device identifier is intended to be a four °dONLNd
∂¡
5Õ
¯)ˇ)character ASCII identifier similar to the,
Courier°dONLNd
‡Õ6Ÿ`(◊6OSType°dONLNd
ÊŒ`⁄√)* identifiers used as °dONLNd
˚Œ√⁄
¯)c<types and creators in the Macintosh file system; they can be
°dONLNd8⁄6Ê
æ(„6Pregistered using the same mechanism used to register creator types. A developer °dONLNdà⁄
æÊ
¯(„
æshould only°dONLNdîÊ6Ú
|(Ô6Kuse a device identifier in this field if they have obtained a registration 
°dONLNdflÊ
|Ú
¯(Ô
|for that identifier's use as°dONLNd¸Ú6˛õ(˚6a creator from Apple.°dONLNd

6

Í*XThe device class is a value which is used to identify the type of device and to control °dONLNdj


Í

¯(

Íthe°dONLNdn
6
"
Ø(
6Racceleration curve used for that device.  The currently defined constants include:°dONLNd¡
.z
:ƒ+DDevice constant°dONLNd—
.

:
V)•Device type"
.…°dONLNdfi
;ú
G¢(
Dú
0°dONLNd‡
;Œ
G
{)2%Tablet device (absolutely positioned)"
:tT"
:… 
: 
:
©"
;…°dONLNd
Gú
S¢(
Pú
1°dONLNd    
GŒ
SÓ)2Mouse"
G…°dONLNd
Sú
_¢(
\ú
2°dONLNd
SŒ
_˙)2    Trackball"
S…
°dONLNd
k¢
w
ã(
t¢(Table 4–Currently defined device classes
°dONLNdG
É6
è±(
å6There currently isn't any °dONLNda
ɱ
è
¯){Cmechanism for developers to create or register device classes; if a°dONLNd•
è6
õ
T(
ò6=developer needs a device class not available from Apple, the 
°dONLNd‚
è
T
õ
¯(
ò
T$only alternative available currently°dONLNd
õ6
ß
>(
§68is not to use the handler ID 4 extended mouse protocol, 
°dONLNd?
õ
>
ß
¯(
§
>%instead using a custom handler ID and°dONLNde
ß6
≥ß(
∞6custom driver software.
°dONLNd}
ø6
À≈*Apple Keyboard protocol
°dONLNdï
◊6
„
Ñ*DThe Apple keyboards have a simple data transfer protocol.  Register °dONLNdŸ
◊
Ñ
„
¯(
‡
Ñ0 is used to inform the
°dONLNdÒ
„6
Ô\(
Ï6host as °dONLNd˘
„\
Ô
¯)&Skeys are depressed and released; register 2 is used to communicate the state of the°dONLNdM
Ô6
˚
õ(
¯6Jmodifier keys and to control the LED indicators on the extended keyboards.°dONLNdò6¥*The format of register 0 is:†Ç

Eå
È    1+\=
|    ˇˇˇˇˇˇˇˇ0*[>
}"*m

"+Ä"+í"+§"+∂"+»"+⁄"*Î"*˝

"+
"+
""+
4"+
F"+
X"+
j°ñ
°öˇ˝

 _,l.
m
§m
§°dONLNdˇˇ+*15†ó°ñ
°öˇ˝

 q,~°dONLNdˇˇ)14†ó°ñ
°öˇ˝

 fl,Ê°dONLNdˇˇ)n
8†ó°ñ
°öˇ˝

 Ò,¯°dONLNdˇˇ)
7†ó°ñ
°öˇ˝

 
,

°dONLNdˇˇ)
6†ó°ñ
°öˇ˝

 
o,
v°dONLNdˇˇ)l
0†ó°ñ
°öˇ˝    

 F,Z°dONLNdˇˇ()GBit:†ó

Eå
È"F
s    "F
a    "F
O    "F
=    "F
+    "F
    "F
    !O
é"Fı!a
é"F„- sws
é Ö
éÖe#¡"F—-"Fø-"F≠-"Fõ-"Fâ-"Fw-°ñ
°öˇ¸#


óã
‡°dONLNdˇˇ(à
òKey 1 released†ó°ñ
°öˇ¸'

m
óy
Ë…¿°dONLNdˇˇ(v
òKey code field 1†ó°ñ
°öˇ¸#

[
óg
‡j¿°dONLNdˇˇ(d
òKey 2 released†ó°ñ
°öˇ¸'

I
óU
˥İdONLNdˇˇ(R
òKey code field 2†ó†É

HR
.



°dONLNdµò´§
É(°´#Figure 3–Keyboard Register 0 Format ¿4¿
˘

(’616)
 of 18)µ9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse+flHardwareˇ HRˇˇˇˇˇRH

HR,Times

.+Z-Developer Technical Support(-
ÁJanuary 1994 /X/
°dONLNd<ZH(EZ]Register 0 can communicate up to two key transitions at once.  Each transition consists of a 
°dONLNd]<H(Ekey°dONLNdaHZTs(QZcode 
°dONLNdfHsT)Wand a key released bit, which is 0 for key depressions and 1 for key releases.  The key°dONLNdæTZ`…(]Zcodes are described in °dONLNd’T…`
)oInside Macintosh°dONLNdÂT
`
V)R volume V, °dONLNdT
V`);'pages 191-192.  The special case is the°dONLNd
`Zlœ(iZreset key, which returns 
°dONLNd
1`œl)uAthe value $7F7F in register 0 when it is depressed and $FFFF when°dONLNd
slZx
Ü(uZBreleased; thus, it uses both key code positions within register 0.°dONLNd
∂ÑZêÿ*The format of register 2 is:†Ç†å

úf
æ    1®}∫
ù    ˇˇˇˇˇˇˇˇ0ß|ª
û"ßé"߆"ß≤"߃"ß÷"ßË"ß˙"ß
"ß
"ß
0

"®
C"®
U"ß
f"ß
x"ß
ä°ñ
°öˇ˝    

ùg©{.

"
©
"
©°dONLNdˇˇ+Bit:†ó°ñ
°öˇ˝

ùÄ©çÅÄ°dONLNdˇˇ)15†ó°ñ
°öˇ˝

ùí©üÅÄ°dONLNdˇˇ)14†ó°ñ
°öˇ˝

ù

©
ÅÄ°dONLNdˇˇ)o
8†ó°ñ
°öˇ˝

ù
©
ÅÄ°dONLNdˇˇ)
7†ó°ñ
°öˇ˝

ù
$©
+ÅÄ°dONLNdˇˇ)
6†ó°ñ
°öˇ˝

ù
ê©
óÅÄ°dONLNdˇˇ)l
0†ó°ñ
°öˇ˝

ù§©±ÅÄ°dONLNdˇˇ(¶•13†ó°ñ
°öˇ˝

ù∂©√ÅÄ°dONLNdˇˇ)12†ó°ñ
°öˇ˝

ù»©’ÅÄ°dONLNdˇˇ)11†ó°ñ
°öˇ˝

ù⁄©ÁÅÄ°dONLNdˇˇ)10†ó°ñ
°öˇ˝

ùÔ©ˆÅÄ°dONLNdˇˇ)
9†ó°ñ
°öˇ˝

ù
6©
=ÅÄ°dONLNdˇˇ)G
5†ó°ñ
°öˇ˝

ù
Z©
aÅÄ°dONLNdˇˇ)$
3†ó°ñ
°öˇ˝

ù
l©
sÅÄ°dONLNdˇˇ)
2†ó°ñ
°öˇ˝

ù
~©
ÖÅÄ°dONLNdˇˇ)
1†ó

úf
æ

"Ã
î"fi
Ç$"
p6"

¶î"

¶Ç 
&
¶
&
 
8
¶
8
 
J
¶
JÚ 
\
¶
\‡ 
n
¶
nΠ
Ä
¶
ĺ 
í™
í
¶ 
§
¶
§ò 
∂
¶
∂Ü √Ü
∂Ü 
§ò√ò √™
í™ 
ĺ√º √Œ
nΠ
\‡√‡ √Ú
JÚ"
8
ã"√
c"

(Ø"√
:?"√
L?"√
^?"
p”"fi
ÇÂ"√
î    °ñ
°öˇ˝,

«
Ø”    °dONLNdˇˇ+1*LED 1 (num lock)†ó°ñ
°öˇ˝,

Ÿ
Ø    Õ¿°dONLNdˇˇ*LED 2 (caps lock)†ó°ñ
°öˇ˝.

Î
ؘ¿°dONLNdˇˇ*LED 3 (scroll lock)†ó°ñ
°öˇ˝

˝
Ø
    
›∑Ä°dONLNdˇˇ*Reserved†ó°ñ
°öˇ˝



Ø

Â\°dONLNdˇˇ*Scroll lock†ó°ñ
°öˇ˝(


!
Ø
-
≠Ä°dONLNdˇˇ*Num lock / clear†ó°ñ
°öˇ˝*


3
Ø
?˘Ä°dONLNdˇˇ*Apple / command†ó°ñ
°öˇ˝


E
Ø
Q
“Û¿°dONLNdˇˇ*Option†ó°ñ
°öˇ˝


W
Ø
c
»HÄ°dONLNdˇˇ*Shift†ó°ñ
°öˇ˝


i
Ø
u
’ùÄ°dONLNdˇˇ*Control†ó°ñ
°öˇ˝



{
Ø
á
ÀG¿°dONLNdˇˇ*Reset†ó°ñ
°öˇ˝


ç
Ø
ô
‡°dONLNdˇˇ*    Caps lock†ó°ñ
°öˇ˝


ü
Ø
´
–ò@°dONLNdˇˇ*Delete†ó°ñ
°öˇ˝


±
Ø
Ω
›ÁÄ°dONLNdˇˇ*Reserved†ó†ç†É

HR
.



°dONLNd
”
 œ
÷
ß(
”œ#Figure 4–Keyboard Register 2 Format
°dONLNd
˜
‚Z
Ó
±(
ÎZKThe current state of the keys listed in figure 4 is available in bits 6-14 °dONLNdB
‚
±
Ó(
Î
±of register 2, if those°dONLNdZ
ÓZ
˙
Å(
˜Z>keys exist on the keyboard being examined.  Bits 0-2 hold the 
°dONLNdò
Ó
Å
˙(
˜
Å current state of the LEDs on the°dONLNdπ
˙Z (Zextended keyboard; the 
°dONLNd–
˙ )pDstates of these LEDs can be changed by sending the keyboard a listen°dONLNdZ
n(Z9register 2 command.  Note that key transition events are °dONLNdN
n(
n$generated in register 0 for modifier
°dONLNdsZ
(Z?keys, as they are for all other keys; these keys are available °dONLNd≤
(
"in register 2 in addition to their°dONLNd’Z*
$('Z,status being transmitted through register 0. ¿X¿

*Æ9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse(’17)
 of 18(ÎZHardwareˇ¬HRˇˇˇˇˇRH

HR,Times

.+6-Macintosh Technical Notes /4/
˘

°dONLNd<6K}*
Miscellany
°dONLNdW6cm*    Licensing°dONLNdo6{™*The Apple Desktop Bus 
°dONLNd,o™{
¯)tEis patented.  In order to build an ADB device, you will need to get a°dONLNdr{6á¿(Ñ6license from Apple.  Contact:°dONLNdêìZü’+$Apple Software Licensing°dONLNd©üZ´¬*Apple Computer, Inc.°dONLNdæ´Z∑¯*20525 Mariani Avenue, M/S 38-I°dONLNd›∑Z√”*Cupertino, CA       95014°dONLNd˜√Zœ•*[phone]°dONLNd
€ZÁŸ*AppleLink: SW.LICENSE°dONLNd
ÁZÛ
6*(Internet: [e-mail]°dONLNd
Eˇ6

(
6.The license is available for a nominal fee in 
°dONLNd
sˇ


¯)Œ2most cases, and the licensing package includes the°dONLNd
¶
6

õ(
6Nlatest version of the ADB spec., which is the definitive reference to the bus.
°dONLNd
ı
#6
/†*Further Reference: 
/4
/
˘°dONLNd
0H
<L+

•°dONLNd

0Z
<
D)0The Apple Desktop Bus specification, revision F.°dONLNd;
<H
HL(
EH
•°dONLNd=
<Z
H´)Inside Macintosh°dONLNdM
<´
H
ú)Q/, Volume V, chapter 20, "The Apple Desktop Bus"°dONLNd}
HH
TL(
QH
•°dONLNd
HZ
T
)&Guide to the Macintosh Family Hardware°dONLNd•
H

T
K)ƒ    , Second 
°dONLNdÆ
H
K
T
¯)-"Edition, Chapter 8, "Apple Desktop°dONLNd—
TZ
`r(
]ZBus" ¿4¿
˘

(’618)
 of 18)µ9HW 1 – ADB - The Untold Story : Space Aliens Ate My Mouse+flHardwareˇ